您会使用ADO.NET实体框架的v3.5，还是等待v4.0？

Question

我很惊讶地发现一封公开信，建议对实体框架投不信任票（见http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/）

信中所述的理由是否会阻止您使用当前版本的实体框架？你宁愿等v4.0吗？或者更确切地说使用另一个ORM？

Answer 1

当前版本的EF绝对不是完美的，并且有很多缺点和缺点。我现在可能不会使用它 - 但EF v2的升级路径（或EF4？）确实看起来很漂亮！

• 完全持久性无知 - 你可以使用你的直接POCO课程
• 延迟加载可配置为选项
• 大大改进了设计师，支持多元化/单一化（即使是多种语言！）
• 能够“从模型开始”设计并从模型中创建数据库
• 跨多个层拥有自我跟踪实体的能力，允许您将数据发送到客户端并获取更改并将其应用于您的实体上下文

总而言之，EF v2看起来很有前途，我非常渴望给它一个严重的旋转。如果它真的保留了所有的承诺，它绝对是赢家！

查看ADO.NET team blog上最近关于EF v2的一系列博文。

马克

Answer 2

另一个ORM。

不要误会我的意思你应该得到回应，但目前只有nHibernate在功能上完整。

我是TDD的粉丝，所以想要一个易于测试的POCO ORM解决方案。如果这是你的包，那么EF3.5就出来了。 EF4.0正在引入它（http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx），但它仍然至少有一个很大的缺点 - ＆gt;不支持继承。

NHibernate更完整，但EF更容易使用。与以往一样，这项工作的最佳工具......但如果它是企业级TDD开发的应用程序，请转到nHibernate。

另外 - ＆gt;有一个分析器，使nHibernate开发更容易 - ＆gt; http://www.nhprof.com/

Answer 3

我尝试将它用于我当前的项目，这基本上涉及重写我们当前混乱的数据层。

它不起作用。

首先，如果您尝试将实体基于View，设计器会尝试强制每个NOT NULL属性为实体键...这几乎不是我想要的。要解决此问题，您必须至少在两个位置编辑xml，并在每次添加对象时执行此操作，因为它会刷新并重新添加EntityKey属性。 Must specify mapping for all key properties in Entity Framework?

其次，当您创建关联时，您必须使用每个实体键 - How can you make an association without using all entity keys in entity framework?

这两件事让我筋疲力尽了3天，然后我又回到了Linq to SQL并在几个小时内完成了它。 （好吧，至少我正在努力的系统部分...）我不知道这些是否在不信任投票中，但在我看来还没有准备好。

由于缺乏答案，我在每个EF问题上都得到了答案，我不得不假设目前的使用率很低，以至于得到帮助和支持很难......这可能是最大的原因而不是用一些东西。

让我们希望下一个版本更好......

编辑：当前的计划是坚持使用Linq 2 SQL（我必须在星期五之前完成一个项目），然后评估所有其他ORM以查看是否还有其他更好的东西。另一位开发者讨厌L2S，但我从来没有遇到任何重大问题......

Answer 4

EF拥有丰富的设计时间支持，但我必须同意nHibernate是可行的方法，尽管有学习曲线。如果您需要快速制作并且不关心TDD或序列化（这是所有MS的ORM产品的一大弱点），请转到EF。

Answer 5

我对第1版的体验很有趣。我想使用POCO，但它不支持它。在阅读完之后，我遇到了一些来自微软公司的人员的代码。

生成代码有点乱，但总的来说这部分过程并不是那么糟糕。

我遇到的一个真正令人讨厌的部分是缺乏内置的并发检查，用于N层开发。你必须自己管理这个问题，看看问题并没有那么糟糕，特别是如果你想将版本回传给客户端以便用户干预。

缺少第二个讨厌和绝对愚蠢的事情是LINQ查询的IN关键字。不支持，所以需要解决。我找到了一个解决方案，但实际上却带来了一些其他代码，这些代码很快就修补了这些遗漏。

我会使用EF 4.0（2.0）吗？是的，绝对，为什么不呢？事实上，在第二阶段，我将使用它。看起来它支持POCO，看起来我的并发模型将直接移动而没有任何问题（基本上是delta拷贝的东西）。到目前为止，这一切都很好，我希望这一次，微软的大家伙已经看到了他们的方式的错误，并提供了一个有效的解决方案。

如果您首先购买实体开发和整个概念模型，那么它是获得完整Microsoft解决方案的唯一途径。虽然在M语言上完成的工作可能会超出这个想法并将整个建模事物移回数据库。

如果你没有购买实体的东西，那么我强烈要求企业库。它是一种经过验证的技术，每次都基于可靠的代码基础和以数据库为中心的范例。如果您认为存储过程是蜜蜂的膝盖并且喜欢它们带来的东西，我也会走这条路。

如果你的感觉真的很奇特，感觉有点活泼，我会选择像CouchDB这样的NO-SQL方法。然而，这确实需要一些人习惯。它该死的怪异，感觉真的非常错误。但是事情在超快的时间内得到了发展，解决方案似乎比预期更强大，更快。如果你对标准化很重要并且认为它可以应用于NO-SQL方法，我不会得到这种类型的解决方案。整个模型需要转移，应用程序需要以应用技术驱动的方式建模。

我发现CouchDB方式有点脏，非常非常错误。但它有很多令人信服的理由使用它，我认为它将渗透到每个程序员的心中，并且它肯定会在未来几年成为主流。

我最大的抱怨仍然是整个实体的事情，即使在新版本4中，确实没有太多考虑到N层环境。它仍然感觉它是一个2层解决方案，最终用户（开发人员）仍然需要完成大量的锅炉板代码，以使其以强大可靠的N-Tier方式工作。