Entity Framework 4 vs NHibernate

Entity Framework 4 vs NHibernate

---

웹에서 Entity Framework 첫 번째 버전에 대해 많은 이야기가 있었으며 (또한 stackoverflow에서도) NHibernate와 같은 더 나은 대안이 이미있을 때 좋은 선택이 아니라는 것이 분명합니다. 그러나 Entity Framework 4와 NHibernate를 잘 비교할 수 없습니다. 오늘 NHibernate는 모든 .NET ORM의 리더라고 말할 수 있지만 Entity Framework 4가 NHibernate를이 위치에서 대체 할 것으로 기대할 수 있습니다. Microsoft가 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로드 및 결과 형성 : EF4 열망로드 시스템 (Include ( "Path"))은 JOIN을 반복하여 부적절한 SQL을 생성합니다. 이로 인해 다 대다 관계에 대해 수천 (문자 그대로는 아님)의 시간이 느리게 실행됩니다. 효과적으로 사용할 수 없습니다).
• Materializer가 연결된 엔터티를 구체화 할 수 없습니다 . 자체 SQL 쿼리를 제공하여 이전 문제를 극복 할 수 있다고 생각하면 잘못되었습니다. EF4는 JOIN SQL 쿼리에서 관련 엔터티를 구체화 (매핑) 할 수 없으며 하나의 테이블에서만 데이터를로드 할 수 있습니다 (따라서 Order.Product, SELECT * FROM order LEFT JOIN이있는 경우 제품은 주문 개체 만 초기화하고 제품은 null로 유지됩니다. 필요한 모든 데이터가 쿼리에서 가져 와서 초기화되었다고 생각했습니다.) 이것은 EFExtensions 커뮤니티 애드온을 사용하여 극복 할 수 있지만,이를 위해 작성해야 할 코드는 실제로 추악합니다 (시도했습니다).

• 자체 추적 엔티티: 많은 사람들은 셀프 트래킹 엔티티 가이 스레드의 최고 답변을 포함하여 N 계층 개발에 적합하다고 말합니다. 나는 그들에게 시도조차하지 않았다고 생각했지만, 그렇지 않다고 말할 수 있습니다. 모든 입력을 위조 할 수 있습니다. 사용자가 보낸 변경 사항을 단순히 데이터베이스에 적용하여 사용자에게 직접 데이터를 제공하지 않는 이유는 무엇입니까? 기본 액세스? 데이터 사용자를로드 해야하는 모든 방법은 DB에서 변경하려고합니다. 존재하지 않는지 확인하십시오. 존재 여부 확인 등을 수행하십시오. 서버로 보내는 엔티티의 상태에 대해 사용자를 신뢰할 수는 없습니다. 이 엔티티를 DB에서로드하고 상태 및 기타 사항을 결정해야하므로 내부 추적을 위해 신뢰할 수있는 개인 n 계층 시스템을 수행하지 않는 한 자체 추적 엔티티와 마찬가지로이 정보는 쓸모가 없습니다. DB 액세스.

• 로깅, 이벤트, 통합 비즈니스 로직 : EF4는 블랙 박스와 비슷하며 어떤 기능을 수행하며 무엇을하는지 전혀 모릅니다. OnSavingChanges 이벤트는 하나만 있습니다 .DB와 관련하여 어떤 일이 발생하기 전에 실행해야 할 비즈니스 로직을 넣을 수 있으며, 어떤 일이 발생하기 전에 비즈니스 객체에 약간의 변경 사항을 적용 해야하는 경우 ObjectStateManager를 파헤쳐 야하며 이는 실제로 추악합니다. 코드가 커질 수 있습니다. 예를 들어 리포지토리 패턴을 사용하고 깨끗한 객체 방식으로 DB의 변경 사항에 대한 알림을받는 경우 EF를 사용 하여이 작업을 수행하는 데 어려움을 겪을 수 있습니다.

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

EF에 대한 나쁜 점을 계속 쓸 수 있고 20 페이지 정도의 작업을하는 것이 얼마나 고통 스러울까요?

NHibernate는 어떻습니까? 그것은 절대적으로 다른 수준이며, PHP를 C #과 비교하는 것과 같습니다. 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이었고 많은 사람들이 그것을 사용합니다.

---

I think the fact that EF 4 will have the ability to use POCO and deferred lazy loading will be very big. I could definitely see it gaining traction with the new release.

---

There is an obvious trend of increasing EF popularity over NHibernate, see the picture.

---

My 2 cents: we use ef on our desktop client for some cahing etc - no hi loads. An NHib on server side - utilizing Stateless sessions, hilo id generation and batches. Is is quite fast in inserting 3k+messages in db per second. Also it is very flexible and supports lots of dbs, wich is crucial for our product.

---

Mapping directly to stored procedures with a combination of Linq for a logical layer seems the easiest approach. No xml. Generate sql only for interesting queries that are less frequently used or not suitable for stored procedures.

Objects load and store through standard SPs. This approach allows the use of two sql logins. One for the class access through SPs (execute-only permissions) and one for a logical linq module that allows direct table access.

---

Choosing between ORM's by popularity isn't the best thing to do. I've tried to move to EF the past 2years and all I can say is, why the hell I still try to?

ATM my point of view about EF is: "It's made for really small pretty tiny bit systems with no more than 3 tables with less than 1 relationship (0 is better)".

And why do I think like that? 1. Try to update a disconnected graph and see your model scratch;

1. Try to make TPH with deep inherited trees and you'll find you that you are schackled to a single hierarchy or the system will break.

2. Try to make more cumbersome queries and watch the whole system eat out the stack :D... overflows happen very often.

3. Map XML datatypes is based on extensions or the most "hated" NotMapped properties... and it's even worse.

4. Try mixing SQL query into Linq for more finner queries and you'll break the wall lol.

5. And the last and most important thing, EF doesn't support property formula ('an awesome resources NH has for legacy databases'), and doesn't support complex type mappings for same table and related tables.

That's my 10cc.

참고URL : https://stackoverflow.com/questions/1639043/entity-framework-4-vs-nhibernate