![]() |
1
25
对于Web应用程序,ef并不是多余的。 我不同意你在参考文章中所说的很多内容。我同意开发人员在SQL方面应该有不错的技能,但是ORM在更快地完成开发人员的工作方面做得很好。
本文讨论了MS最新开发的一些灵感,这些灵感来自RubyonRails。ROR中有一个基于活动记录的ORM….. ORM很好。它们不必在任何地方和每一次都使用,但它们是好的,应该加以考虑。 |
![]() |
2
9
尽管这是一个一般性的回答,但请注意以下任何意见: “X工具很臭,我用Y工具写,我可以比用X工具写得更快。” 当然,说拉丁语的人用拉丁语说得更好。 |
![]() |
3
4
英孚有一条学习曲线,但任何新事物都有。EF并不是杀伤力过大,但根据任何正在编写的系统,都要为正确的项目使用正确的技术。 |
![]() |
4
3
看这篇文章,我首先会看到和不同意的是:
我不确定有多少人查看Web开发,但在我看来,Web开发人员应该关注功能和业务规则。纯数据库和SQL代码不应该由我团队中编写业务功能代码的效率更高的人来完成。 这就是实体框架发挥作用的地方。它被认为是一种快速的应用程序开发工具(大多数其他窗体也是如此)。这些工具是专门为使您能够更加关注如何满足用户需求而构建的,而不是如何正确地编写查询而构建的。 有人这么说,我也会说,幼稚地使用这个工具是危险的。使用实体框架时,您仍然必须了解使用所请求的对象图的含义。 它是迄今为止不过分杀伤力,该工具是非常简单的使用和学习。我认为“修复”实体框架比修复原始SQL查询和ADO事务集更容易。 对于较小的项目,我的基本建议几乎总是与某种ORM一起使用。在企业应用程序中,您必须更加小心,这完全取决于预算:—)。 |
|
5
3
如果正确使用ORM,并且您了解它对您的作用,那么它可能非常有用。如果您已经对数据库设计和查询有了一些了解,那么一定要使用它。 本文的重点主要是,不必学习任何有关数据库设计和查询的知识,这一概念以某种方式使您的生活变得更好,这是一个谬论。我更喜欢代码和数据库之间的薄层抽象——我觉得这让我更加关注良好的用户体验。 我个人认为英孚背后的媒体鼓励新的编码人员忽略一些必要的基础知识。我和他们中的一些人一起工作过,认为他们做了一件坏事。 当然,也有一些人会强烈反对。没问题! 我知道开发人员开始喜欢它,但现在不喜欢。但我也知道开发人员喜欢ef并发誓。 多年来,我一直使用ef、linq-to-sql、nhibernate等。 最好的建议:试一试。得出你自己的结论。 (披露:我是你所引用文章的作者)。 |
![]() |
6
1
绝对不是滥杀。继续使用ef。 |
![]() |
7
1
它实际上取决于数据模型的复杂性,而不是应用程序的类型。 如果您有一个相对简单的数据模型,那么ef可能会被过度杀伤力(如果您还不知道)。linq-to-sql可能是一个更好的选择(学习曲线较少,但它也有一些限制,比如没有多对多的映射)。 如果您的数据模型更为规范化,而不仅仅是基于表的,那么从长远来看,EF或nhibernate,或任何其他更高级的ORM都将得到回报。 您链接到的文章似乎表明ORM一般都是坏的,而不仅仅是EF。当面对他的观点时,他似乎在某种程度上退缩了。他似乎在试图证明一个笼统的概念(即新开发人员在进入高级框架之前必须学习低级编码,特别是SQL)的合理性,方法是创造出有问题的点。 |
![]() |
Haim Ohayon · 这些链接之间有什么区别? 2 年前 |