10个月前关闭
我正在为一个大项目决定一个ORM，并决定采用ADO.NET实体框架，特别是与.NET 4一起提供的新版本。在我搜索EF信息的过程中，我偶然发现了ADO.NET实体框架不信任投票，我不知道该怎么做
不信任投票是在2008年的某个时候写的，目的是说服微软听取对EFV1的具体批评
目前尚不清楚在不信任投票中提出的主张是否仍然有效（在.NET4中），以及它们是否严重到可以使用其他解决方案。NHibernate是一个成熟的选择，但我不知道它会带来什么问题。我通常更倾向于Ms解决方案，主要是因为我可以依靠与VS的集成以及他们对开发人员的支持
我希望能举出一些例子，说明不信任投票中提到的问题如何影响现实世界中的项目更重要的是，在EF for.NET 4中提出的声明是否仍然相关？
我一直认为，“不信任投票”背后的大部分内容都是试图将EF当作NHibernate的克隆品来使用。事实并非如此，即使在EF 4中，试图将EF当作NHibernate仿制品来使用也可能以失败告终，尽管在失败之前您可能会走得更远一些。举一个简单的例子，大多数人在NHibernate中使用LINQ的基础很小，如果有的话，而我认为你在EF中根本就不能有效率，除非你大量使用LINQ
另一方面，我已经相当成功地使用了EF 1本身的条款，并设法不让人们在博客帖子中的声明妨碍它为我工作。我期待着使用EF4中的许多新功能，但我很乐意随时为结构良好的EF1项目工作。（就这一点而言，我也很高兴与NHibernate合作，不会批评它的行为不像EF。）
因此，我试图以一种微妙的方式建议，在你决定“在不信任投票中提出的主张是否仍然有效（在.NET 4中）…”之前，你必须首先决定这些主张对你是否有效，以及你的工作方式。如果你个人对O/R的理解与NHibernate是紧密相连的，那么EF4对你来说可能还是二流的。另一方面，如果你愿意学习英孚的工作方式，那么即使是英孚1也可能比你听说的要好
直接处理“不信任”声明，并检查其实质内容和EF 4中的变化：
过分关注实体的数据方面会导致实体架构降级：
这是对实体框架的实体数据模型的误解。（或者，如果你愿意的话，可以有不同的看法。）但不管怎样，这都是一个特性，而不是一个bug。实体框架是围绕更一般的数据服务而设计的，而不仅仅是O/R建模。将行为放在从数据服务返回的实体上会导致CORBA式的灾难。在某种程度上，与您所处的ORM不同，无论ORM黑盒中的类型是什么，您都需要将实体框架模型投射到业务类型上。在这种情况下，映射的实体类型将永远不会具体化。
这是实体框架模型和许多其他ORM之间的实质性区别。就我个人而言，我发现将业务行为与O/R映射分离比将它们集中在一起要干净得多。你不必同意这个想法，但这显然是一个设计决策，而不是疏忽
处理延迟加载不足所需的多余代码：
EF4无论好坏，都有延迟加载
我之所以说“好还是坏”，是因为延迟加载使得生成多余的数据库查询非常容易。只要你密切关注引擎盖下发生的事情，它就可以正常工作，但大多数人不会这样做。我发现投影在大多数情况下比延迟加载、急切加载或显式加载更好
尽管如此，有时延迟加载还是很方便的。所以我很高兴看到它被添加到EF4中
共享的规范模型与软件最佳实践相矛盾：
很难理解这一点，因为一些支持文本甚至不是连贯的英语，例如：
容易发生故障的规范化模型方法并不困难，因为缺乏沿着实体框架的路线精心设计的工具
这一节似乎暗示了实体框架对复杂系统使用单一、规范的数据模型提出了某种要求，或至少是强烈的偏见。我不确定我是否同意，但鉴于本节中没有任何具体的例子，很难说出来。所以我会告诉你我自己在这个问题上的偏见，你可以同意或不同意我：
根据系统的实际大小，对大型系统使用单一模型通常是错误的。然而，实体框架中的任何内容都不要求您使用单个模型。另一方面，实体框架，尤其是版本1中的实体框架，并没有使组合多个模型变得容易
现在，对于一个复杂的系统来说，一个单一的大型应用程序可能和一个单一的大型数据模型一样大。因此，实体框架使许多微小的模型很容易组合成一个超大的应用程序是不正确的；这只会将一个问题替换为另一个问题
另一方面，我认为用一种适合问题域的方式分区服务来构建一个大型系统是很有意义的。我认为WCF数据服务是一种独立于实体框架的技术，但它非常支持实体框架，因此非常有用
我确实认为，在未来的版本中，实体框架可以使在必要时将两个或三个模型合并到一个应用程序中变得更容易。您现在可以这样做，但需要一些手动操作。但正如我上面所说的，我不想通过促进/鼓励创建一个过大的应用程序来“修复”一个过大数据模型的问题
缺乏持久性无知会导致业务逻辑更难读、写和修改，从而导致开发和维护成本以夸张的速度增加：
本节提出了我认为错误的主张：
实体框架通过阻止在实体类中包含业务逻辑来鼓励缺乏竞争力的领域模型反模式
见上文。我认为实体类型的工作是在对象空间中的关系空间之间进行映射。根据单一责任原则，这些类型只需在其唯一工作发生变化时进行修改。如果业务流程发生变化，那么这是一项与O/R映射无关的职责。也许其他ORM的局限性会对分离这些责任造成技术障碍。当技术要求时，如果设计纯度的成本过高，可以改变规则。但我强烈支持无行为实体类型的方法
在当前状态下，EF实体类无法独立于数据库进行有效的单元测试
这是错误的。写这篇文章的人不明白他们在说什么。我们的单元测试从来没有涉及到DB，而且很多都涉及到EF
就本节标题的实质内容而言，EF 4有所变更。如果这有助于您的设计，那么现在就可以拥有完全不依赖持久性的实体类型。然而，从最早版本的words实体框架开始，您就能够将项目投射到poco上。因此，在需要时，持久性始终是可用的。对实体类型本身的持久性忽略允许使用持久性忽略对象进行更改跟踪。这在某些情况下可能有用。但是，与关于单元测试的虚假声明相比，它是一个小得多的案例子集，这大大减少了文档提出的观点的影响
团队环境中与源代码管理的过度合并冲突：
合并XML真的那么难吗？如果是这样的话，也许应该研究一种新的合并工具。我不觉得这有什么问题