实体框架投票无信心 - 相关于.NET 4？ [英] Entity Framework Vote of No Confidence - relevant in .NET 4?
问题描述
2008年没有信心投票是为了说服微软听取对EF v1的具体批评。
目前还不清楚在无信任投票中提出的声明是否仍然有效（在.NET 4中），以及是否严重使用其他解决方案。 NHibernate是一个成熟的替代方案，但我不知道它带来了什么问题。我通常更倾向于一个Ms解决方案，主要是因为我可以依靠与VS和开发人员支持的集成。
我会欣赏示例<强调无信心投票中提到的问题在现实世界项目中的影响。 更重要的是，在EF中为.NET 4提供的声明是否相关？
我一直觉得，不信任投票的许多东西是尝试使用EF，就像是一个NHibernate克隆一样。它不是，即使在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中的变化：
重点关注实体领导的数据方面降级的实体架构：
这是对实体框架的实体数据模型的误解。 （或者，如果你喜欢，意见的区别。）但无论哪种方式，这是一个功能，而不是一个bug。实体框架围绕更一般的数据服务情况进行设计，而不仅仅是特别是O / R建模。将从行为返回数据服务的实体导致CORBA风格的灾难。与您所在的ORM不同，在某种程度上，坚持使用任何类型的ORM黑盒，您可以使用实体框架模型来预测业务类型。在这种情况下，映射的实体类型将永远不会被实现。
这是实体框架模型和许多其他ORM之间的实质性区别。就个人而言，我发现将业务行为与O / R映射分开比将它们集中在一起更清晰一些。你不必同意这个想法，但这显然是设计决定，而不是监督。
需要处理的EXCESS代码没有LAZY LOADING：
EF 4，无论好坏还是懒惰加载。
我说更好或更坏，因为延迟加载使得生成多余的数据库查询非常容易。只要您密切关注引擎盖下发生的情况，它工作正常，但大多数人不这样做。我发现投影是更好的替代懒惰加载，渴望加载或显式加载大部分时间。
仍然有一段时间，懒惰加载方便。所以我很高兴在EF 4中添加。
共享，经典模型不对称软件最佳做法：
很难知道该做什么，因为一些支持文本甚至不是一致的英语，例如：
根据实体框架的缺陷，缺乏准确的工具并不难，故障倾向的规范模型方法并不困难。
此部分似乎表明，实体框架强加了某种要求，或至少强烈的偏见，使用单一的规范数据模型复杂的系统。我不知道我同意，但很难说，鉴于本节缺乏任何具体的例子。所以我会告诉你我自己对这个问题的偏见，你可以同意或不同意我的观点：
系统，取决于系统实际上有多大。然而，实体框架中的任何内容都不要求您使用单个模型。另一方面，实体框架，特别是在版本1中，并没有使其轻松组合多个模型。
现在，复杂系统的大型应用程序可能与单个大型数据模型一样大错特错。因此，实体框架使许多小型模型能够容易地组合成一个过大的应用程序是不正确的;这只是替换另一个问题。
另一方面，我认为，轻松构建一个从方式适合问题域。我认为，WCF数据服务是一个独立于实体框架的技术，但是支持实体框架的WCF数据服务非常有用。
我认为在未来的版本中，实体框架可以在必要时将两个或三个模型组合到单个应用程序中更容易。你现在可以这样做，但是有一些手工工作。但是如上所述，我不想通过促进/鼓励创建一个过大的应用程序修复一个过大的数据模型的问题。
缺乏持续性的IGNORANCE导致业务逻辑难以阅读，编写和修改，导致开发和维护成本以增加的速度增加：
本节提出我发现错误的索赔：
实体框架鼓励模式通过阻止在实体类中包含业务逻辑。
见上文。我认为实体类型的工作是在对象空间的关系空间之间映射。根据单一责任原则，这些类型只能在其唯一工作变更时才需要修改。如果业务流程发生变化，那么这是与O / R映射无关的责任。其他ORM的限制也可能对分离这些职责构成技术性障碍。如果设计纯度的成本过高，技术要求就可以弯曲规则。但是我非常赞成无行为实体类型的方法。
在当前状态下，EF实体类不能独立于单元测试数据库。
这只是错误的。谁写的这个都不明白他们在说什么。我们的单位测试中没有一个触摸到DB，有许多涉及到EF。
只要本节标题的实质内容有变化对于EF 4.现在可以有完全持久性的无知实体类型，如果这有助于您的设计。但是，从实体框架的最早版本开始，您就可以将其投放到POCO上。所以持久的无知一直在需要时可用。对实体类型本身的持久性无知允许使用持久性无知对象进行更改跟踪。这在某些情况下可能是有用的。但是，相对于关于单元测试的虚假声明来说，这是一个小得多的案例，这减少了文档所产生的影响。
在团队环境中使用源控制进行的过多的并发冲突：
是否将XML实际上难以合并？如果是这样，也许应该研究一个新的合并工具。我没有发现这个问题。
然而，这里存在一个真正的问题，但是再一次，它比文档声明要窄得多。而不是重复，我只是指出你我的帖子
在EF 4中，可以使用代码优先模型而不是XML模型，以将模型拆分成许多不同的文件。
I'm deciding on an ORM for a big project and was determined to go for ADO.NET Entity Framework, specifically its new version that ships with .NET 4. During my search for information on EF I stumbled upon ADO .NET Entity Framework Vote of No Confidence which I'm not sure how to take.
The Vote of No Confidence was written sometime in 2008 to convince Microsoft to listen to specific criticism for EF v1.
It's not clear whether the claims made in the Vote of No Confidence are still valid (in .NET 4) and if they're serious enough to use other solutions. NHibernate is a mature alternative, but I don't know what problems it brings. I'm generally more inclined towards a Ms solution, mainly because I can count on integration with VS and on their developer support.
I would appreciate examples of how the problems mentioned in the Vote of No Confidence affect in real world projects. More importantly, are the claims made there still relevant in EF for .NET 4?
I've always felt that much of what underlay the "vote of no confidence" was an attempt to use the EF as if it were an NHibernate clone. It isn't, and even in EF 4 attempting to use the EF as though it were an NHibernate knockoff is probably going to end in failure, although you may get a little further before failing. As a trivial example, most people use LINQ in NHibernate on a minimal basis, if at all, whereas I don't think you can be productive in EF at all unless you use LINQ quite heavily.
On the other hand, I've been quite successful at using the EF 1 on its own terms, and have managed to not allow claims people make in blog posts to get in the way of making it work for me. I look forward to using many of the new features in EF 4, but I'd be happy to work on a well-structured EF 1 project any time. (For that matter, I'm happy to work with NHibernate, too, and wouldn't criticize it for not acting like the EF.)
So I'm trying to suggest, in a somewhat delicate way, that before you can decide if "the claims made in the Vote of No Confidence are still valid (in .NET 4)..." you must first decide if those claims were ever valid for you and the way you work. If your personal understanding of O/R is hard-wired to NHibernate, then EF 4 is probably still going to seem second-rate to you. If, on the other hand, you're willing to learn the EF way of working, then probably even EF 1 will seem better than you've heard.
To address the "no confidence" claims directly, and examine both their substance and what's changed in EF 4:
INORDINATE FOCUS THE DATA ASPECT OF ENTITIES LEADS TO DEGRADED ENTITY ARCHITECTURES:
This is a misunderstanding of the Entity Framework's entity data model. (Or, a difference of opinion, if you prefer.) But either way, it's a feature, not a bug. The Entity Framework is designed around the more general case of data services, not just O/R modeling in particular. Putting behaviors on entities returned from a data service leads to a CORBA-style disaster. Unlike ORMs where you are, to some degree, stuck with whatever type comes out of the ORM blackbox, with the Entity Framework model you are expected to project onto business types. In this case, the mapped entity types will never even be materialized.
This is a substantive difference between the Entity Framework model and many other ORMs. Personally, I find separating business behaviors from O/R mapping to be quite a bit cleaner than lumping them together. You don't have to agree with this idea, but it is clearly a design decision, not an oversight.
EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING:
The EF 4, for better or worse, has lazy loading.
I say "for better or worse" because lazy loading makes it very easy to generate excess database queries. It works fine so long as you keep a close eye on what's going on under the hood, but most people don't do that. I find projection to be a better alternative to lazy loading, eager loading, or explicit loading most of the time.
Still, there are times when lazy loading is convenient. So I'm glad to see it added in EF 4.
SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES:
It's hard to know what to make of this, as some of the supporting text isn't even coherent English, e.g.:
The failure-prone canonical model approach wasn’t difficult for a lack of elaborate tooling along the lines of the Entity Framework.
This section seems to suggest that the Entity Framework imposes some kind of requirement, or at least strong bias, towards using a single, canonical data model for a complex system. I'm not sure I agree, but it's difficult to tell, given the lack of any specific example in this section. So I'll tell you my own biases on the subject, and you can agree or disagree with me:
It is often a mistake to use a single model for a large system, depending upon how large the system actually is. Nothing in the Entity Framework requires you to use a single model, however. On the other hand, the Entity Framework, especially in version 1, does not go out of its way to make it easy to combine multiple models.
Now, a single, large application for a complex system can be as big of a mistake as a single, large data model. So it would not be correct for the Entity Framework to make it easy to combine many tiny models into one overly large application; that would simply replace one problem with another.
On the other hand, I think it does make sense to make it easy to build a large system out of services partitioned in a way which suits the problem domain. I think that WCF data services, a separate technology from the Entity Framework, but one which supports the Entity Framework very well, are useful for this.
I do think that the Entity Framework could, in some future version, make it easier to combine two or three models into a single application when necessary. You can do this now, but there is some manual work involved. But as I said above, I wouldn't want to "fix" an issue of an overly large data model by facilitating/encouraging creation of an overly large application.
LACK OF PERSISTENCE IGNORANCE CAUSES BUSINESS LOGIC TO BE HARDER TO READ, WRITE, AND MODIFY, CAUSING DEVELOPMENT AND MAINTENANCE COSTS TO INCREASE AT AN EXAGGERATED RATE:
This section makes claims which I find erroneous:
The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes.
See above. I think that the job of the entity types is to map between relational space in object space. Per the Single Responsibility Principle, these types should only need to be modified when their sole job changes. If business processes change, then this is a responsibility unrelated to O/R mapping. Perhaps limitations of other ORMs impose a technical barrier on separating these responsibilities. It's okay to bend rules when technology dictates, if the cost of design purity is excessive. But I strongly favor the approach of behavior-less entity types.
In its current state, EF entity classes cannot be effectively unit tested independently of the database.
This is just wrong. Whoever wrote this didn't understand what they were talking about. None of our unit tests touch the DB, ever, and many involve the EF.
In so far as the substance of the title of this section goes, there is a change for EF 4. It is now possible to have entirely persistence-ignorant entity types, if that helps your design. However, from the earliest version of the Entity Framework on words, you have been able to project onto POCOs. So persistence ignorance has always been available when required. Having persistence ignorance on the entity types themselves allows change tracking with a persistence-ignorant object. That may be useful in some cases. But it's a substantially smaller subset of cases than the bogus claims about unit testing, which lessens the impact of the point the document makes by a lot.
EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS:
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.
这篇关于实体框架投票无信心 - 相关于.NET 4？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
