我听说过有关实体框架的一些不好的事情，我正在考虑使用它。
答案 0 :(得分：5)
如果您从未使用过任何类型的业务实体或O / RM（例如NHibernate或LLBLGen），您可能不会发现很多Entity Framework的缺点。在我的公司，我们评估了所有3个工具，最终选择了LLBLGen，因为这是一种直接使用数据库的简单方法（而不是花费大量时间构建对象模型）。
无论出于何种原因，我们更容易从我们的数据模型开始构建（LLBLGen和EF方法），而不是像NHibernate那样从对象模型开始。我的团队无法真正“获得”实体框架......与LLBLGen合作似乎更难。
带上一粒盐...我们评估了所有3种工具几天，所以我们对EF和NHibernate的体验并不是特别深。
答案 1 :(得分：5)
这里的基本前提是：
开发人员在数据层花费太多时间，编写SQL，担心数据库等。为什么不让框架来处理这个问题。不要担心细节。
这是实体框架和其他ORM的前提。
有关实体框架的一些好处：
建模 没有繁琐的插入，更新类型的东西，少写代码 对象变化跟踪 等等（还有其他人，您可以访问Micorsoft网站了解详情）
但是恕我直言，开发人员应该关注细节。
毕竟，你的开发者，对吧？如果以应用程序数据库为中心，则尤其如此。
这些框架发生了很多“魔术盒活动”。它们是代码生成器。如果不直接使用SP，它们会在运行时生成大量SQL来执行插入，更新等操作。当事情向南（表演，记忆等）时，你如何打开魔术盒？您还必须了解魔术盒如何工作的细节。有时它会做你不希望的事情。
所以，我认为实体框架很有用，但买家要小心。
我认为对于较小的项目来说，当你有一个简单的数据模型并且需要快速完成工作并且不想花时间编写SQL或愚弄DAL时，这将是最有用的。
如果您正在构建一个大型应用程序，这是您业务的核心，我认为您最好花时间预先学习并自己完成所有数据访问，因为当出现问题时（并且会出现问题） ，你将能够直接挖掘并找出解决方案。大多数核心应用程序也持续多年。这些框架的寿命可能比您业务中的核心应用程序短。
答案 2 :(得分：3)
我建议您查看https://stackoverflow.com/questions/tagged/entity-framework，了解有关实体框架及其与其他工具的比较的更多信息。
答案 3 :(得分：2)
我在使用新的Entity Framework 4时遇到了可怕的时间。由于并发性的一个小问题。 实体框架的真正问题是： - 没有正常的网站给我答案或发布我的问题 - 没有好的文件记录好的做法 - 没有关于用它做事的基础知识的教程（单个维度CRUD的每个人都在互联网上发布是没有用的）
最后像大多数ORM一样：很难让它以你需要的方式工作
答案 4 :(得分：1)
Michel - 您的具体问题是什么？我们正在为即将开始的大型项目评估EF。我们有过在大型项目（LLBLGen）上使用ORM的经验，但是通过EF查看@ MS的本地ORM。任何洞察你的痛点都会有所帮助。
您可以在此处找到非常详细的信息： http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
至于最初的问题：我肯定认为EF值得学习，因为我们很可能会多年来听到它。即使你的团队/公司现在没有使用它，它可能会在我们未来的生活中......所以在我看来，调查任何围绕着我们的新兴事物是件好事。
我现在花了大约10个小时进行评估，这是我发现的：
•您对此有何看法？ - 到目前为止，版本4似乎符合最低可接受的ORM功能。
•我应该学习吗？ - 在我看来是的。请参阅上面的评论。
•它的优点是什么？ - VS中的本机工具支持
•它的弱点是什么？ - 我同意另一张海报，其他ORM工具可以更容易。我已经使用LLBLGen大约4年了。我记得它有一个陡峭的学习曲线，但由于某种原因似乎没有花费太多时间。
我发现缺乏强类型包含+帮助模型遍历在包含中有点弱。
同样在之前的版本中，我认为缺乏对FK的支持几乎使EF不可用。
答案 5 :(得分：0)
微软在我看来制定了错误的策略。鼓励开发人员（尤其是新手）使用EF而不是学习SQL的结果是，它以设计不良的应用程序结束，可能会造成性能损失。 我已经看到c＃代码分布在200行，可以用3行SQL编写。
这是我在O / R Mappers中看到的主要问题，缺乏对SQL的理解。叫我老学校; - ）