实体框架是否适用于Web应用程序？

Question

假设我们正在为中小型企业开发电子商务Web应用程序.让我们进一步假设业务可能会随着时间的推移而扩展.换句话说,产品线通常会增长.

到目前为止,我已经在SqlHelper类的帮助下使用ADO.NET和存储过程开发了n层解决方案.对于更大的应用程序,我使用了Enterprise Library(2.0).

我想转向基于ORM的方法,并开始学习LINQ以及从ASP.NET Web Forms切换到ASP.NET MVC.我不想使用LINQ-to-SQL.问题不在于是否需要ORM,而是实体框架ORM对于此类项目是否过度.如果有必要保证手头的任务,我不介意学习曲线.

关于"矫枉过正",我想知道是否:

事实上,如果有人认为ORM对这样的项目来说太过分了,我想听听原因.

Answer 1

EF对于网络应用程序来说并不过分.

我不同意你引用文章中陈述的很多内容.我同意开发人员应该拥有不错的SQL技能但是ORMS在更快地完成开发工作方面做得很好.

ORMS的速度 - 它们一直在变得越来越好,它们允许您调用SP或修改查询以在必要时获得最大速度.还有很棒的分析器用于监控像EFProf这样的ORM性能.
减慢编码过程 - 真的!一旦学会了它就加快了速度.
开发人员需要知道SQL - 我同意.但是,ORMS尤其是LINQ语法通常允许开发人员编写比他们自己更复杂的SQL.
开发人员已经编写了高效的查询 - 真的很棒!!!! 只要问DBA他/她的想法!我碰巧认为我这样做,但其他人也一样.看到问题.:-)
代码膨胀 - 不得不反对,特别是那些有LINQ的代码......它经常使代码更具可读性并经常减少行数.
忘掉LINQ - 这艘船已经航行了.LINQ Rocks !!!! 跟着它或者落后.它不仅仅用在ORMS中.它可以用于对,数组,对象,XML,文件,推特和列表不断进行....了解LINQ.

本文讨论了来自Ruby on Rails的MS最新发展的一些灵感.ROR有一个基于Active Record的ORM .....

ORMS很好.它们不必在任何地方和每次都使用,但它们是好的并且应该被考虑.

我也给这个读了.90%的场景的数据库访问是一个已解决的问题.你重新发明轮子并从你的客户/雇主窃取解决同样的问题.http://ayende.com/Blog/archive/2008/11/21/stealing-from-your-client.aspx (4认同)
L2S未被取代.事实上,在VS 2010中,L2S得到了改进.它只是比EF更有限的范围. (3认同)
有关能够拨打SP的消息的+1!:-) (2认同)

Answer 2

虽然这是一般性答案,但要注意任何有这些评论的意见:

"X工具发臭,我用Y工具编写,我可以比X工具更快地完成."

或者拉丁语的讲者在拉丁语中说得更好.