您对实体框架有何看法？

我听说过有关实体框架的一些不好的事情,我正在考虑使用它.

你对此有何看法？

我应该学习吗？

有什么优点呢？

它的弱点是什么？

Beep beep.. 5

如果您从未使用任何类型的业务实体或O/RM(例如NHibernate或LLBLGen),您可能不会发现很多Entity Framework的缺点.在我的公司,我们评估了所有3个工具,最终选择了LLBLGen,因为这是一种直接使用数据库的简单方法(而不是花费大量时间构建对象模型).

无论出于何种原因,我们更容易从我们的数据模型开始构建(LLBLGen和EF方法),而不是像NHibernate那样从对象模型开始.我的团队无法真正"获得"实体框架......与LLBLGen合作似乎更难.

带上一粒盐...我们评估了所有3种工具几天,所以我们对EF和NHibernate的经验并不是特别深刻.

如果您从未使用任何类型的业务实体或O/RM(例如NHibernate或LLBLGen),您可能不会发现很多Entity Framework的缺点.在我的公司,我们评估了所有3个工具,最终选择了LLBLGen,因为这是一种直接使用数据库的简单方法(而不是花费大量时间构建对象模型).

无论出于何种原因,我们更容易从我们的数据模型开始构建(LLBLGen和EF方法),而不是像NHibernate那样从对象模型开始.我的团队无法真正"获得"实体框架......与LLBLGen合作似乎更难.

带上一粒盐...我们评估了所有3种工具几天,所以我们对EF和NHibernate的经验并不是特别深刻.

这里的基本前提是:

开发人员在数据层中花费太多时间,编写SQL,担心数据库等.为什么不让框架来处理这个问题.不要担心细节.

这是实体框架和其他ORM的前提.

有关Entity Framework的一些好处:

建模没有繁琐的插入,更新类型的东西,少写代码对象更改跟踪等(还有其他,你可以去Micorsoft网站了解详情)

但恕我直言,开发商应该关注细节.

毕竟,你的开发者,对吧？如果以应用程序数据库为中心,则尤其如此.

这些框架发生了很多"魔术盒活动".它们是代码生成器.如果不直接使用SP,它们会在运行时生成大量SQL来执行插入,更新等操作.当事情向南(表演,记忆等)时,你如何打开魔术盒？您还必须了解魔术盒如何工作的细节.有时它会做你不会想到的事情.

所以,我的意见是实体框架是有用的,但买家要小心.

我认为对于较小的项目来说,当你有一个简单的数据模型并且需要快速完成工作并且不想花时间编写SQL或愚弄DAL时,这将是最有用的.

如果您正在构建一个大型应用程序,这是您业务的核心,我认为您最好花时间预先学习并自己完成所有数据访问,因为当出现问题(并且会出现问题)时,您将能够直接挖掘并找出解决方案.大多数核心应用程序也持续多年.这些框架的寿命可能比您业务中的核心应用程序短.