Entity Framework 4 대 NHibernate [닫힌]

웹에서 Entity Framework 첫 번째 버전 (스택 오버 플로우에서도)에 대해 많은 이야기가 있었으며 NHibernate와 같은 더 나은 대안이 이미있을 때 좋은 선택이 아니라는 것이 분명합니다. 그러나 Entity Framework 4와 NHibernate의 좋은 비교를 찾을 수 없습니다. 오늘날 NHibernate가 모든 .NET ORM 중 리더라고 말할 수 있지만 Entity Framework 4가 NHibernate를이 위치에서 대체 할 것으로 기대할 수 있습니다. 나는 마이크로 소프트가 EF4에 정말 좋은 기능을 삽입했다면 그것은 Visual Studio 통합을 가지고 있고, 작업하기 쉽고, 대부분의 상점에서 MS 제품에 대한 선호도가 항상 주어지기 때문에 NHibernate와 좋은 경쟁을 줄 수 있다고 생각합니다.

EF4는 "자체 추적 엔터티"에서 n 계층 개발과 관련하여 즉시 사용 가능한 답변을 제공합니다. 아무도 NHib에 대한 유사한 코드를 공개하지 않았습니다.

NHib에는 EF4의 일부로 언급되지 않은 많은 기능이 있습니다. 여기에는 2 단계 캐시 통합이 포함됩니다. 또한 상속 매핑에서 더 큰 유연성, 저장된 procs / 데이터베이스 함수 / 사용자 지정 SQL / 트리거와의 더 나은 통합, 수식 속성 지원 등을 제공합니다. IMO는 기본적으로 ORM만큼 성숙합니다.

업데이트 : 버전 4.0 이후로 Entity Framework를 사용하지 않았으므로 내 대답이 구식 일 수 있습니다. 내 프로젝트에서 여전히 NH 또는 순수 ADO .NET을 사용하고 있습니다. NH가 완벽하게 작동하기 때문에 4.0 이후 EF의 새로운 기능을보고 싶지도 않습니다.

둘 다 사용하면 실제로 비교하기가 매우 쉽습니다. EF4에는 몇 가지 심각한 제한 사항이 있습니다. 내 자신이 만난 몇 가지 사항은 다음과 같습니다.

EF4 문제 :

• Eager Loading and shaping the result : EF4 eager loading system (Include ( "Path"))은 JOIN을 루핑하여 부적절한 SQL을 생성합니다. 이는 다 대다 관계에 대해 수천 (말 그대로) 더 느리게 실행 된 다음 손으로 작성된 SQL을 실행합니다. 효과적으로 사용할 수 없음).
• Materializer는 관련 엔티티를 구체화 할 수 없습니다 . 자신의 SQL 쿼리를 제공하여 이전 문제를 극복 할 수 있다고 생각하면 잘못된 것입니다. EF4는 JOIN SQL 쿼리에서 관련 엔티티를 구체화 (맵핑) 할 수 없으며 하나의 테이블에서만 데이터를로드 할 수 있습니다 (따라서 Order.Product가있는 경우 SELECT * FROM order LEFT JOIN Product는 Order 개체 만 초기화하고 Product는 null로 유지됩니다. 필요한 모든 데이터를 쿼리에서 가져 와서 초기화한다고 생각했습니다.) 이것은 EFExtensions 커뮤니티 추가 기능을 사용하여 극복 할 수 있지만이를 위해 작성해야하는 코드는 정말 추합니다 (시도했습니다).

• 자체 추적 엔티티: 많은 사람들이이 스레드의 최상위 답변을 포함하여 N 계층 개발에 자체 추적 엔티티가 멋지다고 말합니다. 모든 입력은 위조 될 수 있으며 사용자가 전송 한 변경 사항을 데이터베이스에 적용 할 수 없습니다. 사용자에게 직접 데이터를 제공하는 것은 어떻습니까? 그럼 기본 액세스? 데이터를로드해야하는 방법은 사용자가 DB에서 변경하려고합니다. 존재하지 않는지 확인하고 권한을 확인하는 등의 작업을 수행합니다. 사용자가 서버로 보내는 엔티티의 상태를 신뢰할 수 없습니다. 이 엔터티를 DB에서로드하고 상태 및 기타 사항을 결정해야합니다. 따라서 내부 사용을 위해 신뢰할 수있는 비공개 n-tier 시스템을 사용하지 않는 한 Self-Tracking 엔터티처럼이 정보는 쓸모가 없습니다. DB 액세스.

• 로깅, 이벤트, 비즈니스 로직 통합 : EF4는 블랙 박스와 같으며 어떤 작업을 수행하며 어떤 작업을 수행하는지 전혀 모릅니다. DB에서 어떤 일이 발생하기 전에 실행해야하는 비즈니스 로직을 넣을 수있는 OnSavingChanges 이벤트가 하나 뿐이며, 어떤 일이 발생하기 전에 비즈니스 객체에 일부 변경 사항을 적용해야하는 경우 ObjectStateManager를 파헤쳐 야합니다. 이것은 정말 추합니다. , 코드가 커질 수 있습니다. 예를 들어 Repository 패턴을 사용하고 DB에 대한 변경 사항에 대해 깨끗한 객체 방식으로 알림을 받으면 EF 로이 작업을 수행하기가 어려울 것입니다.

• 확장 성 : 모든 EF 코드는 비공개이며 내부입니다. 만약 당신이 무언가를 좋아하지 않는다면 (그리고 EF 사용에 대해 진지하게 생각한다면 LOT를 좋아하지 않을 것입니다), 결코 쉽게 바꿀 수 없습니다. 사실 저는 확신합니다. ORM을 처음부터 작성하는 것이 더 쉽습니다 (내가 했음). 그런 다음 필요에 따라 EF가 작동하도록합니다. 예를 들어 EFExtensions 소스를 살펴보면 확장 메서드와 다른 "해킹"을 기반으로하여 EF를 좀 더 유용하게 만들 수 있으며 코드는 매우 추합니다 (저자의 잘못이 아닙니다. EF의 모든 것이 비공개 일 때 이것이 유일한 확장하는 방법).

계속해서 EF에 대한 나쁜 내용을 쓸 수 있고, 20 페이지 정도 작업하는 것이 얼마나 고통 스러웠는지, 아마도 그렇게 될 것입니다.

NHibernate는 어떻습니까? 완전히 다른 수준입니다. PHP와 C #을 비교하는 것과 같습니다. EF4는 Stone-age에서와 같습니다. EF가 개발 과정에서 NHibernate보다 10 년 뒤진 것 같습니다. 사실 Hibernate는 2001 년에 시작되었습니다. 자유 시간이 있다면 Nhibernate를 배우고 켜려면 그렇게하십시오.

여기에 문제가 있습니다. NHibernate와 Entity Framework는 실제로 두 가지 다른 대상을위한 것입니다. NHibernate는 복잡한 매핑, 수식 및 제약 조건 (기본적으로 모든 엔터프라이즈)을 사용하여 시스템을 구축 할 때 제가 선택한 것입니다. 간단한 데이터 액세스로 현장에서 실행하려면 Entity Framework 또는 LINQ-to-SQL을 사용합니다. NHibernate는 EF와 같은 명확한 "끌어서 놓기"경험이 없습니다. 둘 다 장점과 단점이 있습니다. 솔직히 말해서 사과와 사과를 비교하면 아무데도 얻을 수 없습니다.

Mono에서 코드를 실행하고 싶다고 생각한다면 기능 체크리스트가 뭐라고하든 NHibernate가 더 나은 선택 일 것입니다.

2012 년 8 월 13 일 수정 :

Entity Framework는 오픈 소스되었으며 이제 2.11.3부터 ​​Mono에 포함되었습니다. 이 답변은 이제 구식이며 신뢰할 수 없습니다.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

내 생각은 EF4.0이 1.0 이후로 먼 길을 왔고 기능면에서 Nhibernate를 따라 잡고 있지만 아직 전부는 아닙니다.

그러나 그것은 바로 Microsoft이며 95 %의 응용 프로그램에서 필요한 작업을 100 % 수행합니다. 그러나 NHibernate는 수년 동안 같은 일을 해왔습니다. 버전 5.0 또는 6.0은 NHibernate를 따라 잡거나 능가 할 수 있습니다.

여기에 제 조언이 있습니다. 둘 다 배울 시간이 있다면 그렇게하세요. 하나를 선택해야하는 몇 가지 이유가 있습니다. 기업용 코드를 작성하는 경우 모든 책과 아이들이 대학에서 배우는 내용과 같이 EF에 익숙한 유능한 직원이 될 것으로 기대하는 것이 현실적입니다. EF가 귀하의 요구 사항을 충족 할 수 있다면 (예라고 말하기 전에 오랫동안 열심히 생각해보십시오), 현재로서는 완벽하게 훌륭한 솔루션이며 몇 년 안에는 NHibernate를 능가 할 수 있습니다.

NHibernate는 EF에서 몇 년 동안 사용 된 매우 성숙한 제품이며, 당신이하고 싶은 모든 일을 할 것입니다. 그것은 한동안 최고의 ORM이었고 많은 사람들이 그것을 사용합니다.

EF 4가 POCO를 사용할 수 있고 지연된 지연 로딩이 매우 클 것이라고 생각합니다. 나는 그것이 새로운 릴리스와 함께 견인력을 얻고 있음을 확실히 볼 수 있었다.

NHibernate보다 EF 인기가 높아지는 분명한 추세 가 있습니다. 그림을 참조하십시오.

내 2 센트 : 우리는 데스크탑 클라이언트에서 ef를 사용하여 일부 캐싱 등을 수행합니다. 서버 측의 NHib-Stateless 세션, hilo id 생성 및 배치 활용. 초당 3k 이상의 메시지를 db에 삽입하는 것이 매우 빠릅니다. 또한 매우 유연하고 많은 dbs를 지원하므로 제품에 매우 중요합니다.

논리 계층에 대한 Linq 조합을 사용하여 저장 프로 시저에 직접 매핑하는 것이 가장 쉬운 방법 인 것 같습니다. xml이 없습니다. 자주 사용되지 않거나 저장 프로 시저에 적합하지 않은 흥미로운 쿼리에 대해서만 SQL을 생성합니다.

개체는 표준 SP를 통해로드 및 저장됩니다. 이 접근 방식을 사용하면 두 개의 SQL 로그인을 사용할 수 있습니다. 하나는 SP를 통한 클래스 액세스 (실행 전용 권한) 용이고 다른 하나는 직접 테이블 액세스를 허용하는 논리적 linq 모듈 용입니다.

인기에 따라 ORM을 선택하는 것은 최선의 방법이 아닙니다. 나는 지난 2 년 동안 EF로 이사하려고 노력했고 내가 말할 수있는 것은, 왜 내가 아직도 노력하고 있는가?

ATM EF에 대한 나의 관점은 : "1 개 미만의 관계를 가진 3 개 이하의 테이블 (0이 더 좋음)을 가진 매우 작은 아주 작은 비트 시스템을 위해 만들어졌습니다.")

그리고 왜 그렇게 생각합니까? 1. 연결이 끊어진 그래프를 업데이트하고 모델 스크래치를 확인하십시오.

1. 깊은 상속 된 트리를 사용하여 TPH를 만들려고하면 단일 계층 구조로 엉망이되거나 시스템이 중단된다는 것을 알게됩니다.

2. 더 성가신 쿼리를 작성하고 전체 시스템이 스택을 소모하는 것을 확인하십시오. : D ... 오버플로가 매우 자주 발생합니다.

3. Map XML 데이터 유형은 확장 또는 가장 "혐오스러운"NotMapped 속성을 기반으로하며 더 나쁩니다.

4. 더 많은 쿼리를 위해 Linq에 SQL 쿼리를 혼합하면 벽을 허물 수 있습니다.

5. 마지막으로 가장 중요한 것은 EF가 속성 수식 ( '레거시 데이터베이스에 대한 NH의 멋진 리소스')을 지원하지 않으며 동일한 테이블 및 관련 테이블에 대해 복잡한 형식 매핑을 지원하지 않는다는 것입니다.

그것은 내 10cc입니다.