Entity Framework 무 신임 투표-.NET 4와 관련이 있습니까?

Entity Framework 무 신임 투표-.NET 4와 관련이 있습니까?

---

큰 프로젝트를 위해 ORM을 결정하고 있으며 ADO.NET Entity Framework, 특히 .NET 4와 함께 제공되는 새 버전을 사용하기로 결정했습니다. EF에 대한 정보를 검색하는 동안 ADO .NET Entity Framework 투표를 발견했습니다. 불신임 내가 가지고하는 방법을 잘 모르겠어요있다.

불신임 투표는 Microsoft가 EF v1에 대한 특정 비판을 듣도록 설득하기 위해 2008 년에 작성되었습니다.

No Confidence의 주장이 여전히 유효한지 (.NET 4에서) 그리고 다른 솔루션을 사용할만큼 심각한 지 여부는 명확하지 않습니다. NHibernate는 성숙한 대안이지만 어떤 문제가 발생하는지 모르겠습니다. 나는 주로 VS와의 통합 및 개발자 지원에 의존 할 수 있기 때문에 일반적으로 Ms 솔루션에 더 관심이 있습니다.

무 신뢰 투표에 언급 된 문제가 실제 프로젝트에 어떤 영향을 미치는지 예를 들어 감사하겠습니다 . 더 중요한 것은 .NET 4 용 EF에서 주장 된 주장이 여전히 관련이 있습니까?

---

나는 항상 "신뢰할 수없는 투표"를 뒷받침하는 많은 부분이 마치 NHibernate 클론 인 것처럼 EF를 사용하려는 시도라고 느꼈습니다. 그렇지 않습니다. EF 4에서도 EF를 마치 NHibernate 넉 오프 인 것처럼 사용하려는 시도는 실패로 끝나 겠지만 실패하기 전에 조금 더 나아갈 수 있습니다. 사소한 예로, 대부분의 사람들은 NHibernate에서 최소한의 기준으로 LINQ를 사용하지만, LINQ를 아주 많이 사용하지 않는 한 EF 에서 생산성 을 전혀 발휘할 수 없다고 생각합니다 .

다른 한편으로, 나는 EF 1을 그 자체로 사용하는데 상당히 성공적이었고, 사람들이 블로그 게시물에서 주장하는 것이 나를 위해 작동하도록 방해하지 않도록 관리했습니다. EF 4의 많은 새로운 기능을 사용할 수 있기를 기대하지만 언제든지 잘 구성된 EF 1 프로젝트에서 작업하게되어 기쁩니다. (그 문제에 대해서는 NHibernate와 함께 일하게되어 기쁘고 EF처럼 행동하지 않는다고 비판하지 않을 것입니다.)

그래서 저는 다소 섬세한 방식으로 "신뢰 투표에서 이루어진 주장이 여전히 유효한지 (.NET 4에서) ..."여부를 결정하기 전에 먼저 그러한 주장을 결정해야한다고 제안하려고합니다. 했다 당신과 방법에 대한 지금까지 유효한 당신이 작동합니다. O / R에 대한 개인적인 이해가 NHibernate에 연결되어 있다면 EF 4는 여전히 두 번째 속도로 보일 것입니다. 반면에 EF 작업 방식을 기꺼이 배우고 싶다면 아마도 EF 1조차도 당신이들은 것보다 더 좋아 보일 것입니다.

"신뢰할 수 없음"주장을 직접 해결하고 그 내용과 EF 4에서 변경된 사항을 모두 조사합니다.

엔터티의 데이터 측면에 초점을 맞추면 엔터티 아키텍처가 저하됩니다.

이것은 Entity Framework의 엔터티 데이터 모델에 대한 오해입니다. (또는 선호하는 경우 의견의 차이입니다.) 그러나 어느 쪽이든 버그가 아니라 기능입니다. Entity Framework는 특히 O / R 모델링뿐만 아니라보다 일반적인 데이터 서비스 사례를 중심으로 설계되었습니다. 데이터 서비스에서 반환 된 엔터티에 동작을 적용하면 CORBA 스타일의 재난이 발생합니다. 당신이있는 ORM과는 달리, 어느 정도는 ORM 블랙 박스에서 나오는 모든 유형을 고수하고 Entity Framework 모델을 사용하면 비즈니스 유형에 투영 할 것으로 예상됩니다. 이 경우 매핑 된 엔티티 유형이 구체화되지도 않습니다.

이것은 Entity Framework 모델과 다른 많은 ORM 간의 실질적인 차이입니다. 개인적으로 저는 O / R 매핑에서 비즈니스 행동을 분리하는 것이 하나로 묶는 것보다 훨씬 더 깔끔하다는 것을 알게되었습니다. 이 아이디어에 동의 할 필요는 없지만 감독이 아닌 디자인 결정입니다.

지연로드 부족을 처리하는 데 필요한 초과 코드 :

EF 4는 좋든 나쁘 든 지연 로딩이 있습니다.

지연 로딩은 과도한 데이터베이스 쿼리를 생성하기 매우 쉽기 때문에 "좋든 나쁘 든"이라고 말합니다. 후드 아래에서 무슨 일이 일어나고 있는지 면밀히 관찰하는 한 잘 작동하지만 대부분의 사람들은 그렇게하지 않습니다. 대부분의 경우 지연로드, 즉시로드 또는 명시 적로드에 대한 더 나은 대안이 프로젝션 이라고 생각 합니다.

그래도 지연 로딩이 편리한 경우가 있습니다. 그래서 EF 4에 추가 된 것을 보게되어 기쁩니다.

공유 된 표준 모델 계약 소프트웨어 모범 사례 :

일부 지원 텍스트가 일관된 영어가 아니기 때문에이를 어떻게해야하는지 알기가 어렵습니다. 예 :

실패하기 쉬운 표준 모델 접근 방식은 Entity Framework의 라인에 따른 정교한 도구가 부족하기 때문에 어렵지 않았습니다.

이 섹션 은 Entity Framework가 복잡한 시스템에 대해 단일 표준 데이터 모델을 사용하는 것에 대해 일종의 요구 사항 또는 최소한 강한 편향을 부과한다고 제안하는 것 같습니다 . 동의하는지 잘 모르겠지만이 섹션에 구체적인 예가 없기 때문에 말하기는 어렵습니다. 그래서 나는 당신에게 주제에 대한 내 편견을 말할 것입니다. 당신은 저에 동의하거나 동의하지 않을 수 있습니다.

시스템이 실제로 얼마나 큰지에 따라 대규모 시스템에 단일 모델을 사용하는 것은 종종 실수입니다. 그러나 Entity Framework에는 단일 모델을 사용할 필요가 없습니다. 반면에 Entity Framework, 특히 버전 1의 경우 여러 모델을 쉽게 결합 할 수 있습니다.

이제 복잡한 시스템을위한 하나의 대규모 애플리케이션은 하나의 대규모 데이터 모델만큼 큰 실수가 될 수 있습니다. 따라서 Entity Framework가 많은 작은 모델을 하나의 지나치게 큰 응용 프로그램으로 쉽게 결합하는 것은 옳지 않습니다. 그것은 단순히 한 문제를 다른 문제로 대체합니다.

다른 한편으로는 문제 영역에 맞는 방식으로 분할 된 서비스로 대규모 시스템을 쉽게 구축하는 것이 합리적이라고 생각합니다. Entity Framework와는 별개의 기술이지만 Entity Framework를 매우 잘 지원하는 WCF 데이터 서비스가이를 위해 유용하다고 생각합니다.

Entity Framework는 향후 버전에서 필요할 때 두 개 또는 세 개의 모델을 단일 응용 프로그램으로 결합하는 것을 더 쉽게 만들 수 있다고 생각합니다. 지금이 작업을 수행 할 수 있지만 몇 가지 수동 작업이 필요합니다. 그러나 위에서 말했듯이 지나치게 큰 응용 프로그램의 생성을 촉진 / 장려함으로써 지나치게 큰 데이터 모델의 문제를 "수정"하고 싶지 않습니다.

지속성 무지가 부족하면 비즈니스 로직이 읽기, 쓰기, 수정이 더 어려워지고 개발 및 유지 관리 비용이 급격히 증가합니다.

이 섹션은 내가 잘못된 주장을합니다.

Entity Framework는 엔터티 클래스에 비즈니스 논리를 포함하지 않도록하여 Anemic Domain Model 안티 패턴을 권장합니다.

위 참조. 엔티티 유형의 역할은 객체 공간의 관계형 공간을 매핑하는 것이라고 생각합니다. 단일 책임 원칙에 따라 이러한 유형은 유일한 작업이 변경 될 때만 수정해야합니다. 비즈니스 프로세스가 변경되면 이는 O / R 매핑과 무관 한 책임입니다. 다른 ORM의 제한으로 인해 이러한 책임을 분리하는 데 기술적 장벽이있을 수 있습니다. 설계 순도의 비용이 과도하면 기술이 요구할 때 규칙을 구부리는 것이 좋습니다. 그러나 나는 행동이없는 엔티티 유형의 접근 방식을 강력히 선호합니다.

현재 상태에서 EF 엔터티 클래스는 데이터베이스와 독립적으로 효과적으로 단위 테스트 할 수 없습니다.

이것은 단지 잘못된 것 입니다. 이 글을 쓴 사람은 그들이 말하는 내용을 이해하지 못했습니다. 우리의 단위 테스트는 DB를 건드리지 않으며 많은 사람들이 EF를 포함합니다.

이 섹션의 제목의 내용에 관한 한 EF 4에 대한 변경 사항이 있습니다. 디자인에 도움이된다면 이제 완전히 지속성을 무시하는 엔터티 유형을 가질 수 있습니다. 그러나 단어에 대한 Entity Framework의 초기 버전부터 POCO에 투영 할 수있었습니다. 따라서 지속성 무지는 필요할 때 항상 사용할 수있었습니다. 엔터티 유형 자체에 대한 지속성 무시를 사용하면 지속성 무시 개체로 변경 내용을 추적 할 수 있습니다. 어떤 경우에는 유용 ​​할 수 있습니다. 그러나 이는 단위 테스트에 대한 가짜 주장보다 훨씬 작은 사례의 하위 집합이므로 문서가 만드는 요점의 영향을 크게 줄입니다.

팀 환경에서 소스 제어와의 과도한 병합 충돌 :

Is merging XML actually that difficult? If so, perhaps one should look into a new merge tool. I don't find this problematic.

However, there is a real issue here, although, again, it's a lot more narrow than the document claims. Rather than repeat myself, I'll just point you towards my post on that subject.

In EF 4, one can use code-first models rather than XML models in order to split up a model into many different files.

---

Entity Framework has improved since version 1 and this blog post from a NHibernate contributor compares NHibernate and Entity Framework 4.0.

---

EDIT: THIS USED TO BE TRUE, BUT IT'S NOT ANYMORE.

As a person who has used both Entity Framework and NHibernate... I strongly suggest NHibernate. Normally if a FOSS and a MS tech are present, I suggest the MS tech, but I strongly disagree with that for EF. I use EF4 on a day-to-day basis at work, and we have to create a lot of workaround because of EF. Two years ago I used EF for about one year, and then I changed companies, and I've been working with EF for the past year. NHibernate, 2 years ago, is ahead of EF4.

Here's the points they brought up.

Excessive Merge Conflicts With Source Control in Team Environments:

This was partially fixed, from what I hear. They moved the position data for the designer to the bottom of the .edmx, so it's no longer a horrible problem, but still annoying. If me and a co-worker both try modifying the .edmx at the same time, we tend to get horrible merge conflicts because the entire bottom of the file is used to store the position data of the tables in the designer. Our workaround to this problem is to use SVN file locking so we don't double-edit it. Or I ignore locking, and if I get a merge conflict, I just accept their changes and redo my work. Most of my changes aren't so large they take very long to re-do. If this was the only problem, I'd live with it.

If you're using code-first (in EF 4.1) this is a non-issue.

Excess Code Needed to Deal With Lack of Lazy Loading:

They added lazy loading in 4.0.

But it's loading still preforms like a piece of trash. Eager loading is slow, which is a common optimization when you need to speed up your code. I'm running into cases where I have to make 10k+ calls to the database when I'd rather use eager loading. We've timed it, and in many cases it's faster to make multiple database calls (doing myobject.TablenameReference.Load() in a loop) to a local database then it is to use .Include("Tablename"). Yes, I know it's very counter-intutivie, but the numbers don't lie. Also, there's no way to specify the fetch stragety, so you can't specify to Join-fetch or not. So I'd say it's improved, but not near as good as NHibernate.

Inordinate focus on the data aspect of entities leads to degraded entity architectures:

Yeah, this is still as true. Again a good example is order.Status. We'd really like that to be an enum, but because of the way EF is designed, we don't have any other choice besides making it a string. They may fix the enum problem in the future, but the lack of control between the how the mapping is done between the table and the object is the true complaint. NHibernate lets you specify methods for doing mappings, to deal with this case.

To extend a point from Craig Stuntz's response, EF is designed around if you want to take the data model, and select directly from it. (IE myModel.Orders.Where(order => order.Status == "NEW").Select(order => order.Customer.FirstName, order=> order.Customer.LastName).) EF's model ends up being really hard to write automated tests around if you don't want to hit up the DB. If you want a repository, where you ask for an object that meets some criteria, and it returns the whole object, that's what NHibernate works better at. (IE var order = myOrderRepository.GetByStatus(OrderStatus.New)).

Another problem I have with EF is it's total lack of extensiblity. One problem we have is we have Enums for order status. But if we do myModel.Orders.Where(order => order.Status == OrderStatus.New.ToString()), EF will crash on that query because it doesn't know the .ToString() method. It uglifies our code a lot because we can't add support for that. Also there are a lot of internal methods, so we need to cause a odd behavior to happen, we can't do that.

If you're using NHibernate, Linq adds a lot of features to nhibernate that make it much better. Using a conventions-based model, it requires very little code for most of your mappings. If you're using an existing database, Nhibernate lets you specify non-standard conventions to use, and then have them map up, and everything is easily managed. EF 4.0 (and I don't think 4.1) doesn't have support for anything like that.

I hope this helps you out.

---

There is lazy loading in EF 2, http://microsoftpdc.com/Sessions/FT10?type=wmvhigh

참고URL : https://stackoverflow.com/questions/2403816/entity-framework-vote-of-no-confidence-relevant-in-net-4