Persistence Ignorance Scale을 유지할 수 있습니까?

Question

나는 NHibernate와 Linq2Sql에 대해 간략하게 살펴 봤다. 또한 Entity Framework를 살펴보고자합니다.

제기되는 질문은 내가 이러한 ORM에 대해 이야기 할 때 "확장 할 수 없습니다"라고 할 수 있습니까? Google은 규모를 확장 할 수 있다는 인상을 받았지만 궁극적으로 지불 할 가격이 있어야한다고 생각합니다. 더 단순한 비즈니스 계층을 더 많이 지불 할 가치가 있습니까?

Answer 1

이것은 좋은 질문이며 IMHO는 맞춤 DAL과 마찬가지로 확장 할 수 있습니다. 필자는 nHibernate만을 사용 했으므로 시스템과 시스템을 확장하는 데 도움이되는 기능에만 집중할 것입니다.

• 지연로드 - 지연로드를 지원하므로 불필요한 항목을로드하지 않아도됩니다. 물론 Select n + 1 문제를주의해야하지만 시스템에 문제가 발생하지 않도록해야합니다.
• Eager Fetching - SQL에 대한 추가 트립을 피할 수있게하는 데 필요한 객체를 열심히 가져 오는 다양한 방법이 있습니다.
• 2 차 레벨 캐시 - nHibernate는 DB 로의 이동을 줄임으로써 확장 성을 높이는 데 사용할 수있는 2 차 레벨 캐시를 지원합니다. 다양한 유연성을 제공하는 여러 가지 배킹 제공 업체가 있습니다.
• SQL 작성 - nHibernate에서 저장 프로 시저를 호출하거나 엔티티를 반환 할 인라인 SQL 쿼리를 제공 할 수 있습니다. 이렇게하면 생성 된 sql이이를 자르지 않을 때 자신의 SQL을 사용할 수 있습니다. 예를 들어 재귀 쿼리를 사용하여 자체 조인 트리를 로딩하는 경우.

이제는 사용자 지정 DAL 레이어를 처음 조정하는 것이 더 쉽다고 생각합니다. 사용자가 자신의 구성에 익숙하고 미세 조정할 수 있기 때문입니다. 그러나 좋은 ORM은 많은 부분을 최적화시켜줍니다. 당신은 단지 그것을 배우는 약간의 시간을 보낼 필요가 있습니다.

성능이 중요한 코드 영역이 있고 응용 프로그램의 작은 영역에 대해 ORM을 사용할 수 없다면 사용자 지정 DAL 계층을 직접 구축 할 수 있습니다. 팩토리에서 만든 리포지토리와 같은 적절한 디자인 패턴을 사용하는 경우 저장소의 구현을 스왑 아웃하면됩니다.

Answer 2

Hibernate Shards은 가로 확장을 허용하는 ported to NHibernate입니다.

sharding을 구현하는 this one과 같은 멋진 해킹도 있습니다.

그래서 대답은 '예'입니다. NHibernate는 무시 무시하고 완전하게 투명하게 확장 할 수 있습니다.

Answer 3

ORM에 내장 된 앱이 확장 성이 좋지 않다고 말하는 것은 잘못되었습니다. 부주의하거나 게으른 개발자가 ORM을 악용하기 전에 끔찍하게 비효율적 인 SQL을 생성하는 코드를 작성한 것은 확실합니다. 공연 응용 프로그램을 빌드한다는 것은 모든 아름다운 추상화 이 실제로 후드 아래을 수행하는 것에 대해 이해하는 것을 의미합니다. 그러나이 덫에서 벗어나지는 않습니다. ORM을 사용한다고해서 SQL 프로파일 러 또는 NHibernate Profiler이 열리지는 않습니다.

SP가 훨씬 더 빠르다는 주장과 관련하여 this과 this을 읽으십시오. 게다가 ORM (NHibernate, 적어도)은 필요하다면 SP를 사용할 수있는 아주 쉬운 방법을 제공합니다.