EF 已经推出一段时间了，我正在考虑对其进行评估 - 你的经历是什么？
我对 Web 和桌面应用程序都感兴趣，可能还会对 EF 和您使用的其他 ORM 工具进行一些比较。
学习曲线是一个因素，因为有一个团队参与其中。这东西是臃肿的一团糟，还是又瘦又尖？
我听说 Microsoft 正在内部大量使用它，所以这是一个好兆头。如果您对它如何适应 MS 似乎正在花钱的基于云的未来有任何想法，那也可能很有趣。毕竟，如果这是我们最终可能需要知道的事情，那将把优先级提高一两个档次。
非常感谢！
【问题讨论】：
标签： .net entity-framework orm
嗯，我刚刚在 EF 中实现了一个完整的系统，这是我在生产环境中第一次真正体验 EF。该应用程序现在运行了大约 45 天，每天有 100 名用户使用它，没有任何问题。
我认为最大的事情是你必须改变你的想法。如果您像关系数据库 ORM 一样思考，那么您已经有了错误的心态。您需要考虑部分方法、对象和扩展。一旦你掌握了基本的心态，事情就会开始流动（并且你从一开始就重写了很多代码）。
很难获得帮助
EF 的另一个令人沮丧的部分是，无论你去哪里寻求帮助，到处都是 L2S 大佬，他们认为他们已经知道你需要做的所有事情，并一直试图告诉你放弃它，只使用 L2S...如果我愿意已经询问了如何在 L2S 中做到这一点，那么他们的意见可能是有效的......
EF 工作正常
生成可以通过部分方法扩展的对象的基本功能运行良好。实际上，我在早期阶段非常沮丧，因为我一直在尝试以 SQLCommand 中的方式获取内容。一旦您意识到您可以根据业务逻辑的需求而不是 SQL 的工作方式进行思考，您就可以完成更多工作。
例如 - 我一直在尝试进行连接以获取与特定 FK 相关的各种任务的列表。一旦我最终发现我可以将整个 where 子句交给 EF 并弄清楚如何快速将数据返回给我，代码实际上要快得多。
包括臭味
不过，Include 语法对我来说就像是一个 hack。必须使用 .Include("TableName.DetailTable") 是丑陋的。也许我只是被智能感知宠坏了，但我讨厌那种语法。
按需加载
主细节加载也有点难看。如果您不想包含它们，您可以随时参考它们并查看它是否为 .IsLoaded，然后调用 .Load。为什么？对象不能为我做那件事吗？我最终在我的对象上实现了一个扩展方法，如果我尝试加载一个未加载的细节类，它会按需加载它。似乎应该内置在我身上。
注意：上面提到的过滤记录集的详细加载并不复杂，但也不明显。您可以使用 Lambda 表达式进行过滤。
您是否曾经想要移动项目？
这是一个重要原因：非供应商锁定。如果您曾经想将该代码带到另一个数据库，那么您无法使用 Linq2SQL 执行此操作。没有提供者模型。您可能有机会将 EF 系统转移到另一个供应商。在我的情况下，相同的项目在 SQL Server 和 VistaDB EF (Alpha) 上运行，无需更改代码。所以我可以 xcopy 部署它，或者在运行时选择连接到服务器。
【讨论】：
编辑（是的，3 年后）...我不再讨厌 EF...Entity Framework 4.1 及更高版本很棒 - 它（最终）解决了它在过去的。请注意，不是“4.0”，而是“4.1”最终删除了“魔术字符串”等丑陋的用法。它有 Contains 和其他所有内容以及更多内容。
我个人讨厌英孚。我喜欢 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...，并且您想从 AccountTypeID == 9 的 Accounts 表中选择所有帐户，那么在 EF.. . EF 会隐藏该字段，并让您提供 AccountType 类的实例。
所有这些问题都在 L2S 中得到解决。
编辑：哦，你确实问过“你的经历是什么......”而不仅仅是关于问题。在我的新工作中，他们有一个 205 个表的数据库、600 多个存储过程等。我想在编程的新世界中架起一座桥梁……所以我将 DAL 转换为 1-1 “将所有表拖入”使用 EF 的版本。这是它的样子：Giant EDM
仅仅 1 周后，由于我上面提到的问题以及其他一些问题，我不得不把它撕掉并用 L2S 替换它。
【讨论】：
Contains 现在可用，是的。但仍然对其可怕的性能发出警告：stackoverflow.com/a/8108643/270591
在为一个新项目 (ASP.Net/WCF) 试用 EF 后，我发现：
查询非常容易通过 LINQ 实现。 大多数情况下，生成的 T-SQL 都在赚钱。
主要缺乏对 N 层应用程序的支持。
在 n 层 asp.net 应用程序中，管理对象上下文的实例同样痛苦。
EF 设计器缺乏一些明显的功能，总是深入研究 XML。
更新会导致代价高昂的数据库往返，或者有非常晦涩难懂的方法来尝试避免它们。
基于 POCO 和 SP 的 n/tier 应用程序的性能下降非常明显。 这是意料之中的，但没有达到我们注意到的程度。即使在编译查询之后。
由于易于查询，我们在开发中节省的时间很快就被浪费在尝试执行以前简单的任务上。
正如 Brain 所说，通过字符串引用实体类型或表名非常烦人并且感觉非常混乱，我发现自己编写了包装器来从一个点返回这些。
如果你想使用单层应用，那么我们遇到的许多问题可能并不适用。
但对我们来说，我们正在密切关注 V2 并希望有一些改进。
【讨论】：