实体框架是否对Web应用程序的杀伤力过大?

对于Web应用程序,ef并不是多余的。

我不同意你在参考文章中所说的很多内容。我同意开发人员在SQL方面应该有不错的技能,但是ORM在更快地完成开发人员的工作方面做得很好。

• ORM的速度-他们正在 更好的是,他们允许你 调用sp或将查询修改为 必要时获得最大速度。此外,还有许多优秀的配置文件监视ORM性能,例如 EFProf .

• 减慢编码过程- 真的?!!!一旦学会,它就会加速 起来。

• 开发者需要了解SQL-我同意。 但是,ORMS尤其是LINQ 语法通常允许devs写更多 复杂的SQL 他们自己的。

• devs已经在写有效的查询了-真的!!!!!问问DBA他/她的想法!我想我会的,但其他人也一样。看到问题了。-)

• 代码膨胀-必须不同意,尤其是那些有LINQ的代码。它经常使代码更具可读性,并经常减少行数。

• 别提林肯了-这艘船 航行。摇滚!!!!去吧! 落在后面。它不仅仅用于ORM。它可以用于,数组,对象,XML,文件,twitter和列表等等。了解Linq。

本文讨论了MS最新开发的一些灵感,这些灵感来自RubyonRails。ROR中有一个基于活动记录的ORM…..

ORM很好。它们不必在任何地方和每一次都使用,但它们是好的,应该加以考虑。

尽管这是一个一般性的回答,但请注意以下任何意见:

“X工具很臭,我用Y工具写,我可以比用X工具写得更快。”

当然,说拉丁语的人用拉丁语说得更好。

英孚有一条学习曲线,但任何新事物都有。EF并不是杀伤力过大,但根据任何正在编写的系统,都要为正确的项目使用正确的技术。

看这篇文章,我首先会看到和不同意的是:

我坚信现代网络 开发人员应:

爱数据库。

编写高效的查询。

最小化代码。

设计不言而喻的用户界面。

快速工作。

我不确定有多少人查看Web开发,但在我看来,Web开发人员应该关注功能和业务规则。纯数据库和SQL代码不应该由我团队中编写业务功能代码的效率更高的人来完成。

这就是实体框架发挥作用的地方。它被认为是一种快速的应用程序开发工具(大多数其他窗体也是如此)。这些工具是专门为使您能够更加关注如何满足用户需求而构建的,而不是如何正确地编写查询而构建的。

有人这么说,我也会说,幼稚地使用这个工具是危险的。使用实体框架时,您仍然必须了解使用所请求的对象图的含义。

它是迄今为止不过分杀伤力,该工具是非常简单的使用和学习。我认为“修复”实体框架比修复原始SQL查询和ADO事务集更容易。

对于较小的项目,我的基本建议几乎总是与某种ORM一起使用。在企业应用程序中,您必须更加小心,这完全取决于预算:—)。

如果正确使用ORM,并且您了解它对您的作用,那么它可能非常有用。如果您已经对数据库设计和查询有了一些了解,那么一定要使用它。

本文的重点主要是,不必学习任何有关数据库设计和查询的知识,这一概念以某种方式使您的生活变得更好,这是一个谬论。我更喜欢代码和数据库之间的薄层抽象——我觉得这让我更加关注良好的用户体验。

我个人认为英孚背后的媒体鼓励新的编码人员忽略一些必要的基础知识。我和他们中的一些人一起工作过,认为他们做了一件坏事。

当然,也有一些人会强烈反对。没问题!

我知道开发人员开始喜欢它,但现在不喜欢。但我也知道开发人员喜欢ef并发誓。

多年来,我一直使用ef、linq-to-sql、nhibernate等。

最好的建议:试一试。得出你自己的结论。

(披露:我是你所引用文章的作者)。

绝对不是滥杀。继续使用ef。

它实际上取决于数据模型的复杂性,而不是应用程序的类型。

如果您有一个相对简单的数据模型,那么ef可能会被过度杀伤力(如果您还不知道)。linq-to-sql可能是一个更好的选择(学习曲线较少,但它也有一些限制,比如没有多对多的映射)。

如果您的数据模型更为规范化,而不仅仅是基于表的,那么从长远来看,EF或nhibernate,或任何其他更高级的ORM都将得到回报。

您链接到的文章似乎表明ORM一般都是坏的,而不仅仅是EF。当面对他的观点时,他似乎在某种程度上退缩了。他似乎在试图证明一个笼统的概念(即新开发人员在进入高级框架之前必须学习低级编码,特别是SQL)的合理性,方法是创造出有问题的点。