나는 NHibernate와 Linq2Sql에 대해 간략하게 살펴 봤다. 또한 Entity Framework를 살펴보고자합니다.Persistence Ignorance Scale을 유지할 수 있습니까?
제기되는 질문은 내가 이러한 ORM에 대해 이야기 할 때 "확장 할 수 없습니다"라고 할 수 있습니까? Google은 규모를 확장 할 수 있다는 인상을 받았지만 궁극적으로 지불 할 가격이 있어야한다고 생각합니다. 더 단순한 비즈니스 계층을 더 많이 지불 할 가치가 있습니까?
이것은 좋은 질문이며 IMHO는 맞춤 DAL과 마찬가지로 확장 할 수 있습니다. 필자는 nHibernate만을 사용 했으므로 시스템과 시스템을 확장하는 데 도움이되는 기능에만 집중할 것입니다.
이제는 사용자 지정 DAL 레이어를 처음 조정하는 것이 더 쉽다고 생각합니다. 사용자가 자신의 구성에 익숙하고 미세 조정할 수 있기 때문입니다. 그러나 좋은 ORM은 많은 부분을 최적화시켜줍니다. 당신은 단지 그것을 배우는 약간의 시간을 보낼 필요가 있습니다.
성능이 중요한 코드 영역이 있고 응용 프로그램의 작은 영역에 대해 ORM을 사용할 수 없다면 사용자 지정 DAL 계층을 직접 구축 할 수 있습니다. 팩토리에서 만든 리포지토리와 같은 적절한 디자인 패턴을 사용하는 경우 저장소의 구현을 스왑 아웃하면됩니다.
Hibernate Shards은 가로 확장을 허용하는 ported to NHibernate입니다.
sharding을 구현하는 this one과 같은 멋진 해킹도 있습니다.
그래서 대답은 '예'입니다. NHibernate는 무시 무시하고 완전하게 투명하게 확장 할 수 있습니다.
ORM에 내장 된 앱이 확장 성이 좋지 않다고 말하는 것은 잘못되었습니다. 부주의하거나 게으른 개발자가 ORM을 악용하기 전에 끔찍하게 비효율적 인 SQL을 생성하는 코드를 작성한 것은 확실합니다. 공연 응용 프로그램을 빌드한다는 것은 모든 아름다운 추상화 이 실제로 후드 아래을 수행하는 것에 대해 이해하는 것을 의미합니다. 그러나이 덫에서 벗어나지는 않습니다. ORM을 사용한다고해서 SQL 프로파일 러 또는 NHibernate Profiler이 열리지는 않습니다.
SP가 훨씬 더 빠르다는 주장과 관련하여 this과 this을 읽으십시오. 게다가 ORM (NHibernate, 적어도)은 필요하다면 SP를 사용할 수있는 아주 쉬운 방법을 제공합니다.
지속성/ORM을 스케일링한다는 것은 무엇을 의미합니까? –
하하,이 질문은 바위 –
우리의 웹 응용 프로그램에서 병목 현상은 데이터베이스입니다 결과적으로 우리의 비즈니스 로직은 데이터베이스에 가장 적합한 것을 중심으로 구축되었습니다. 지속성에 대한 무지는 DB를 희생하여보다 유연한 비즈니스 계층을 제공합니다. 규모를 조정할 때 지속성을 무시할 수 있습니까? – danswain