EF已经出现了一段时间了，我正在考虑对它进行评估 - 你的经历是什么？
我对网络和桌面应用程序感兴趣，也许您在EF和其他ORM工具之间进行了一些比较。
学习曲线是一个因素，因为有一个团队参与。这个东西是一个臃肿的混乱，还是瘦而尖锐？
我听说微软正在内部和大范围使用它，所以这是一个好兆头。如果你对它如何适应基于云的未来有任何想法，那么MS似乎在这些日子里花钱，这也可能很有趣。毕竟，如果这是我们最终可能需要知道的事情，那么将优先级提高一两级。
非常感谢！
答案 0 :(得分：6)
好吧，我刚刚在EF中完成了一个完整的系统，这是我第一次在生产环境中使用EF的真实体验。该应用程序现在运行大约45天，每天有100个用户点击它，没有任何问题。
我认为最重要的是你必须改变你的想法。如果您正在考虑关系数据库ORM，那么您已经有了错误的心态。你需要考虑部分方法，对象和扩展。一旦你掌握了基本思维方式，事情就会开始流动（你从第一次开始时就重写了很多代码）。
获取帮助粗略
EF的另一个令人沮丧的部分是，无论你去寻求帮助的地方到处都是L2S傻瓜，他们认为他们已经知道你需要做的一切，并且一直试图告诉你放弃它并且只是使用L2S ...如果我愿意的话已经询问如何在L2S中做到这一点，那么也许他们的意见是有效的......
EF工作正常
生成可以通过部分方法扩展的对象的基本功能很有效。我实际上在早期阶段非常沮丧，因为我一直试图按照我在SQLCommand中的方式来做事。一旦你意识到你可以考虑业务逻辑需要什么而不是SQL如何工作，你可以做更多的工作。
例如 - 我一直在尝试进行连接，以获取特定FK与各种任务相关的事项列表。一旦我终于弄清楚我可以将整个claus交给EF，并想出如何快速将数据发回给我，代码实际上要快得多。
包含臭味
但Include语法对我来说就像是一个黑客。必须使用.Include（“TableName.DetailTable”）是UGLY。也许我只是被intellisense宠坏了，但我讨厌这种语法。
按需加载
主细节加载也有点难看。如果您不想包含它们，您可以随时获取它们的参考，看看是否.IsLoaded然后调用.Load。为什么？对象不能为我这样做吗？我最终在我的对象上实现了一个扩展方法，如果我尝试加载未加载的详细信息类，它会按需加载它。似乎应该已经内置了我。
注意：上面提到的过滤记录集的详细信息加载并不复杂，但也不明显。您可以使用Lambda表达式进行过滤。
您是否想要移动项目？
这是一个重要原因：非供应商锁定。如果您想将该代码带到另一个数据库，则无法使用Linq2SQL。没有提供者模型。您可能有机会将EF系统移至其他供应商。在我的情况下，相同的项目在SQL Server和VistaDB EF（Alpha）上运行，无需更改代码。所以我可以在运行时选择xcopy来部署它，或者连接到服务器。
答案 1 :(得分：1)
编辑（是的，3年后）...我不再讨厌EF ...实体框架4.1及以上版本很棒 - 它（最终）解决了它在其中遇到的所有问题/失败过去。注意，不是“4.0”，而是“4.1”最终删除了“魔术字符串”等的丑陋使用。它有Contains以及其他所有内容以及更多内容。
我个人讨厌EF。我喜欢LINQ-2-SQL。以下是关于EF的具体警告：
1）EF不支持“包含”功能。所以，如果你有一个10,000个'账户'的表，并且你想要返回一些用户提供了ID列表的账户......你必须下载所有10,000个并进行for循环。
2）EF不支持延迟加载：http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx
3）如果您有一个简单的“类型”表，例如AccountType ...并且您想从Accounts表中选择AccountTypeID == 9的所有帐户，那么在EF中没有一种干净的方法。 EF会隐藏该字段，并使您提供AccountType类的实例。
所有这些问题都在L2S中得到解决。
编辑：哦，你确实问过“你的经历是什么......”而不只是问题。在我的新工作中，他们有一个205表数据库，600多个存储过程等等。我想把差距缩小到新的编程世界......所以我将DAL转换为1-1“拖动所有表格”使用EF的版本。这是它的样子：Giant EDM仅仅一周之后，由于我上面提到的问题，我不得不将其撕掉并用L2S替换它。还有一些。
答案 2 :(得分：1)
在为新项目（ASP.Net/ WCF）试用EF后，我发现：
通过LINQ查询非常容易实现。 大多数情况下，生成的T-SQL都是有钱的。
主要缺乏对N层应用程序的支持。
在n层的asp.net应用程序中，对对象上下文的实例管理同样痛苦。
EF Designer缺乏一些明显的功能，总是潜入XML。
更新会导致代价高昂的数据库往返，或者使用疯狂的模糊方法来尝试避免它们。
POCO＆amp; amp; amp; amp; amp; P＆amp;基于SP的n / tier应用程序。 这是预期的，但不是我们注意到的延伸。即使在编译查询之后也是如此。
由于易于查询，我们在开发中节省的时间很快就失去了尝试执行以前简单的任务。
当Brain接触到时，通过字符串引用实体类型或表名称是非常烦人的并且感觉非常混乱，发现自己编写包装器以从单点返回这些。
如果您想使用单层应用，那么我们遇到的许多问题可能都不适用。
但是对于我们来说，我们一直在关注V2，希望能有所改进。