2012-01-18 3 views
2

저는 Scala를 약 6 개월 동안 사용해 왔지만 Lift 프레임 워크를 사용하고 있습니다. Lift 문서에서는 기본 매퍼 항목이 제공되지만 ORM (또는 유사한)을 사용할 수 있다고 언급되어 있습니다.Lift의 컨텍스트에서 ScalaQuery를 사용하는 좋은 예는 무엇입니까?

Lift가있는 대체 ORM을 사용하는 좋은 예가 있습니까? (주석 처리되지 않은 출처는 괜찮습니까?) ScalaQuery 사용에 관심이 있지만 제안 사항에 대해 열려 있습니다. 내 유일한 요구 사항은 lib 디렉토리가 MSSQL을 지원해야한다는 것입니다. 내가 본 바로는 JTDS JDBC 드라이버를 사용하는 것으로 끝나고 당신은 경주를 떠납니다.

+0

나는 당신이하고 싶은 것을 정말로 이해하지 못합니다. 매퍼 (Mapper) 도구와 다른 도구를 사용하여 일부 쿼리를 수행 하시겠습니까? –

+0

대부분 @ChrisJamesC 예. 나는 어떤 이슈가 발생할 것이며 관련된 모든 움직이는 부분에 대한 좋은 설명이 있는지 궁금해했다. 아래에서 hedefalk의 대답은 내가 찾고있는 것입니다. 미안 특정 답변을 너무 막연한 경우. –

답변

4

Mapper가 아닌 리프트에서 ORM을 사용하려면 SquerylRecord를 확인하는 것이 좋습니다. 이것은 좋은 출발점이되어야합니다 : http://www.assembla.com/spaces/liftweb/wiki/Squeryl

나는 정말로 ScalaQuery ORM이 아니라 SQL 쿼리를위한 Scala DSL을 고려할 것입니다. 그러나 ORM이 필요하지 않다면 정말 좋은 옵션이라고 생각합니다. 또한 스칼라 통합 쿼리로 수행중인 작업을 확인하십시오 : http://days2011.scala-lang.org/node/138/279. 아직 생산 용으로 사용할 준비가되어 있지 않다고 생각합니다.

+1

FWIW, 나는 실제로 이것에 동의하지 않는다; ScalaQuery는 Squeryl보다 월등합니다 (IMO). 이는 맛의 문제 일 수 있지만 Lift에서 데이터베이스 레이어를 사용하기 위해 특별히 필요한 것은 필요하지 않습니다. – timothy

+0

레코드가 꽤 깨지거나 미완성이므로 SquerylRecord를 사용하여 레코드를 거의 얻을 수 없습니다. Squeryl은 임의의 한계로 가득 차 있으며 데이터베이스에 대해 여러 가지 나쁜 가정을합니다. 또한 유형 안전성을 제공하기가 훨씬 적습니다. ScalaQuery를 사용하여 자체 모델 객체를 롤링하는 것은 항상 squeryl의 한계와 씨름하려고하는 것보다 훨씬 쉽습니다. –

+0

나는 각각에 대해 거의 예제를 코딩하지 않았고 나는 비슷한 결론을 내렸다. 나는 ScalaQuery의 문법을 좋아하고 DB와 대화하는 것이 더 적은 부두처럼 보입니다. SquerylRecord는 유익했습니다. –