我一直认为，“不信任投票”背后的大部分原因是试图将 EF 当作 NHibernate 克隆来使用。事实并非如此，即使在 EF 4 中尝试像 NHibernate 仿制品一样使用 EF 也可能会以失败告终，尽管您可能会在失败之前走得更远。举一个简单的例子，大多数人在 NHibernate 中至少使用 LINQ（如果有的话），而我认为在 EF 中你无法提高工作效率at all除非你非常频繁地使用 LINQ。
另一方面，我在使用 EF 1 本身方面非常成功，并且设法不让人们在博客文章中提出的主张妨碍我使用它。我期待使用 EF 4 中的许多新功能，但我很乐意随时参与结构良好的 EF 1 项目。 （就此而言，我也很高兴与 NHibernate 合作，并且不会批评它不像 EF 那样行事。）
因此，我试图以一种微妙的方式建议，在您决定“不信任投票中提出的主张是否仍然有效（在 .NET 4 中）...”之前，您必须首先决定这些主张是否有效是对你和方式永远有效you work.如果您个人对 O/R 的理解是硬连接到 NHibernate 的，那么 EF 4 对您来说可能仍然是二流的。另一方面，如果您愿意学习 EF 的工作方式，那么甚至 EF 1 可能看起来比您听说的更好。
要直接解决“不信任”声明，并检查其实质内容以及 EF 4 中的更改：
不注重实体的数据方面会导致实体架构退化：
这是对实体框架实体数据模型的误解。 （或者，如果您愿意，也可以提出意见分歧。）但无论哪种方式，它都是一个功能，而不是一个错误。实体框架是围绕更一般的数据服务案例而设计的，而不仅仅是 O/R 建模。将行为放在从数据服务返回的实体上会导致 CORBA 式的灾难。与 ORM 不同，在某种程度上，您会受制于 ORM 黑匣子中出现的任何类型，而使用实体框架模型，您需要将其投影到业务类型上。在这种情况下，映射的实体类型甚至永远不会被具体化。
这是实体框架模型和许多其他 ORM 之间的实质性区别。就我个人而言，我发现将业务行为与 O/R 映射分开比将它们混在一起要干净得多。你不必同意这个想法，但这显然是一个设计决策，而不是一个疏忽。
处理缺乏延迟加载所需的多余代码：
无论好坏，EF 4 都具有延迟加载功能。
我说“无论好坏”是因为延迟加载很容易生成过多的数据库查询。只要您密切关注幕后发生的事情，它就可以正常工作，但大多数人不会这样做。我发现投影 http://blogs.teamb.com/craigstuntz/2009/12/31/38500/大多数时候是延迟加载、预先加载或显式加载的更好替代方案。
尽管如此，有时延迟加载还是很方便的。所以我很高兴看到 EF 4 中添加了它。
共享的规范模型冲突软件最佳实践：
很难知道这是怎么回事，因为一些支持文本甚至不是连贯的英语，例如：
由于缺乏与实体框架类似的复杂工具，容易失败的规范模型方法并不困难。
本节seems表明实体框架对复杂系统使用单一规范数据模型施加了某种要求，或者至少是强烈的偏见。我不确定我是否同意，但鉴于本节中缺乏任何具体示例，因此很难说。所以我会告诉你我自己在这个问题上的偏见，你可以同意或不同意我的观点：
对大型系统使用单一模型通常是错误的，具体取决于系统的实际大小。然而，实体框架中没有任何内容要求您使用单一模型。另一方面，实体框架（尤其是版本 1）并没有竭尽全力使多个模型的组合变得容易。
现在，复杂系统的单个大型应用程序可能会像单个大型数据模型一样犯下严重错误。因此，实体框架让将许多微小模型轻松组合到一个过大的应用程序中是不正确的；这只会用一个问题代替另一个问题。
另一方面，我认为通过以适合问题域的方式划分的服务轻松构建大型系统确实有意义。我认为 WCF 数据服务对此很有用，它是一种独立于实体框架的技术，但它很好地支持实体框架。
我确实认为，在未来的某个版本中，实体框架可以在必要时更轻松地将两个或三个模型组合到单个应用程序中。您现在可以执行此操作，但涉及一些手动工作。但正如我上面所说，我不想通过促进/鼓励创建过大的应用程序来“解决”过大的数据模型的问题。
缺乏持久性的无知导致业务逻辑更难读、写和修改，导致开发和维护成本以夸张的速度增加：
本节提出了我认为错误的主张：
实体框架通过阻止在实体类中包含业务逻辑来鼓励贫血领域模型反模式。
往上看。我认为实体类型的工作是在对象空间中的关系空间之间进行映射。根据单一职责原则，这些类型仅在其唯一工作发生变化时才需要修改。如果业务流程发生变化，那么这是与 O/R 映射无关的责任。也许其他 ORM 的限制对分离这些职责造成了技术障碍。当技术要求时，如果设计纯粹性的成本过高，那么改变规则是可以的。但我强烈支持无行为实体类型的方法。
在当前状态下，EF 实体类无法独立于数据库进行有效的单元测试。
这是错误的 https://stackoverflow.com/questions/2372030/testing-ef-sql-server-based-application-with-in-memory-sqlite/2372137#2372137。写这篇文章的人不明白他们在说什么。我们的单元测试从来没有接触过 DB，而且许多单元测试都涉及 EF。
就本节标题的实质内容而言，EF 4 发生了变化。现在可以拥有完全与持久性无关的实体类型（如果这有助于您的设计）。但是，从最早版本的单词实体框架开始，您就可以投影到 POCO 上。因此，在需要时，持久性无知总是可用的。对实体类型本身具有持久性无知，允许使用持久性无知的对象进行更改跟踪。这在某些情况下可能很有用。但与有关单元测试的虚假声明相比，它的案例子集要小得多，这大大减少了该文档所提出观点的影响。
团队环境中的合并与源代码控制存在过多冲突：
合并 XML 实际上有那么困难吗？如果是这样，也许人们应该研究一种新的合并工具。我不认为这有问题。
然而，这里存在一个真正的问题，尽管它再次比文件声称的范围要窄得多。我不会重复自己，而是会向您指出我关于这个主题的帖子 http://blogs.teamb.com/craigstuntz/2010/02/03/38542/.
在 EF 4 中，可以使用代码优先模型而不是 XML 模型，以便将模型拆分为许多不同的文件。
