实体框架VS LINQ to SQL VS ADO.NET与存储过程？

Question

实体框架VS LINQ to SQL VS ADO.NET与存储过程？

Bri*_*per 424 sql ado.net linq-to-entities entity-framework linq-to-sql

你会如何评价每一个:

性能
发展速度
整洁,直观,可维护的代码
灵活性
总体

我喜欢我的SQL,因此一直是ADO.NET和存储过程的忠实粉丝,但我最近玩过Linq to SQL,并且被写出我的DataAccess层的速度和决定花费的速度感到震惊有一段时间真正理解Linq to SQL或EF ......或者两者都没有？

我只是想检查一下,这些技术中没有一个很大的缺陷会让我的研究时间变得毫无用处.例如,性能非常糟糕,对于简单的应用程序来说它很酷,但只能带你到目前为止.

更新: 您可以专注于EF VS L2S VS SP而不是ORM VS SP.我主要对EF VS L2S感兴趣.但我很想将它们与存储过程进行比较,因为普通的SQl是我所了解的很多东西.

Answer 1

Dav*_*kle 427

首先,如果您正在开始一个新项目,请使用Entity Framework("EF") - 它现在可以生成更好的SQL(更像Linq to SQL)并且比Linq to SQL更容易维护和更强大(" L2S").自.NET 4.0发布以来,我认为Linq to SQL是一种过时的技术.MS对于不再继续进行L2S开发持开放态度.

1)表现

这很难回答.对于大多数单实体操作(CRUD),您会发现这三种技术具有相同的性能.您必须知道EF和Linq如何使用SQL才能充分利用它们.对于像轮询查询这样的高容量操作,您可能希望让EF/L2S"编译"您的实体查询,以便框架不必不断地重新生成SQL,或者您可能遇到可伸缩性问题.(见编辑)

对于更新大量数据的批量更新,原始SQL或存储过程总是比ORM解决方案执行得更好,因为您不必通过线路将数据封送到ORM来执行更新.

2)发展速度

在大多数情况下,EF会在开发速度方面吹走裸露的SQL /存储过程.EF设计人员可以在数据库更改时(根据请求)更新您的模型,因此您不会遇到目标代码与数据库代码之间的同步问题.我不会考虑使用ORM的唯一一次是当您在进行报告/仪表板类型的应用程序时,您没有进行任何更新,或者您正在创建应用程序只是为了对数据库执行原始数据维护操作.

3)整洁/可维护的代码

放下手,EF击败SQL/sprocs.由于您的关系是建模的,因此代码中的连接相对较少.对于大多数查询,实体的关系对于读者来说几乎是不言而喻的.没有什么比从层到层调试或通过多个SQL /中间层进行更糟糕的了解,以便了解数据实际发生了什么.EF以非常强大的方式将您的数据模型带入您的代码中.

4)灵活性

存储过程和原始SQL更"灵活".您可以利用sprocs和SQL为奇怪的特定情况生成更快的查询,并且您可以比使用ORM更轻松地利用本机数据库功能.

5)整体而言

不要陷入选择ORM与使用存储过程的错误二分法. 您可以在同一个应用程序中使用它们,您可能应该使用它们.大批量操作应该存储在存储过程或SQL中(实际上可以由EF调用),EF应该用于CRUD操作和大多数中间层的需求.也许您会选择使用SQL来编写报告.我猜这个故事的寓意与以往一样.使用正确的工具完成工作.但它的一点点是,EF现在非常好(从.NET 4.0开始).花一些时间阅读并深入了解它,您可以轻松创建一些令人惊叹的高性能应用程序.

编辑:EF 5通过自动编译的LINQ查询简化了这一部分,但是对于真正的高容量,你肯定需要测试和分析在现实世界中最适合你的东西.

绝对精彩的答案.我现在确实使用EF来快速开发应用程序.如果性能成为一个问题,将引入存储过程来重构性能不佳的EF查询.谢谢! (35认同)
@BritishDeveloper:另外,不要忘记使用视图的强大功能.我们在L2S项目中定义了几个视图并在框架似乎编写不良查询的情况下利用它们取得了巨大的成功.这样,我们获得了使用框架的所有好处,并具有编写自己的SQL的所有好处. (17认同)
我也在使用Views;)更多的是解决EF的非交叉数据库限制.但是,用于优化的好主意.谢谢 (5认同)
绝对是一个很好的回应.只想添加一个我自己使用L2S vs EF4的经验观察.在我们意识到我们可能正在使用几个不同的RDMBS之后,从L2S - > EF4交换了...但是,在仍然运行MSSQL时,性能下降主要显示在我的应用程序的GUI区域中.在L2S中对结果集的数据绑定比EF4快得多.这是完全相同的DB上完全相同的查询.这里要注意的一件事是我要返回90k +记录,所以差异非常明显.也许在较小的套装上,这不是问题吗？不知道如何使用高容量网站进行扩展...... (5认同)
反应很好.我花了4个星期的时间与LINQ-to-Entities合作,尝试将所有东西都塞进去,然后终于意识到你需要原生SQL来进行批量复制,批量删除,从数据库中快速删除重复数据等等.适合这项工作的工具,将本机SQL与LINQ to Entities框架混合在一起并不羞耻. (5认同)
EF使用和保存要好得多.Code First是.NET缺失的东西.我会使用SQL来处理复杂的场景,使用EF来处理其他任何事情.如果某些特定项目存在任何性能问题,只需测试该项目并检查它是否不是源代码,如果它确实是EF,请更改为纯SQL.提示:如果可能的话,将SQL字符串保存在单个类中并引用它们(因此只需更改一次SQL并避免重复编码等). (3认同)

Answer 2

小智 91

存储过程:

(++)

灵活性极大
完全控制SQL
可用的最高性能

( - )

需要SQL知识
存储过程不受源代码管理
大量的"重复自己",同时指定相同的表和字段名称.重命名数据库实体并在某处遗漏某些引用后,很有可能破坏应用程序.
发展缓慢

ORM:

(+)

快速发展
数据访问代码现在受源代码管理
您与数据库中的更改隔离开来.如果发生这种情况,您只需要在一个地方更新模型/映射.

( - )

表现可能更差
对ORM产生的SQL没有或几乎没有控制(可能是效率低下或更糟糕的错误).可能需要干预并使用自定义存储过程替换它.这将使您的代码变得混乱(代码中的一些LINQ,代码中的一些SQL和/或源代码控制中的DB).
任何抽象都可以产生"高级"开发人员,他们不知道它是如何工作的

一般的权衡是在具有很大的灵活性和失去大量时间与限制你可以做的事情之间,但要快速完成.

这个问题没有一般的答案.这是一场神圣的战争.还取决于手头的项目和您的需求.选择最适合你的方法.

我不认为有关源控制的要点是相关的.数据库模式,存储过程,UDF等都可以并且应该受源代码控制. (47认同)
"因为任何抽象都可以产生"高级"开发人员不知道它是如何工作的 (15认同)
因此,我们放弃了"快速开发"的灵活性,完全控制和性能,并在DB更改时避免代码更改.对我来说听起来像是懒惰. (4认同)
同意,源控制参数不正确.我们总是将数据库创建脚本存储在svn中.在开发数据库应用程序时,如何将数据库保持在源代码控制之外？ (3认同)
EF不是真正适合高可用性和高性能,我不是DBA的人,但我不知道EF提供什么,这使得编码更容易. (2认同)

Answer 3

Bla*_*ICE 18

你的问题基本上是O/RM和手写SQL

使用ORM或纯SQL？

看看那里的一些其他O/RM解决方案,L2S不是唯一的(NHibernate,ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

解决具体问题:

取决于O/RM解决方案的质量,L2S非常擅长生成SQL
一旦你理解了这个过程,使用O/RM通常要快得多
代码通常也更整洁,更易于维护
Straight SQL当然会为您提供更大的灵活性,但大多数O/RM可以完成除最复杂查询之外的所有操作
总的来说,我建议使用O/RM,灵活性损失可以忽略不计

Answer 4

Mar*_*tos 13

LINQ-to-SQL是一项非常出色的技术,使用起来非常简单,并且总体上会为后端生成非常好的查询.LINQ-to-EF计划取代它,但历史上一直非常笨拙地使用并生成了远低于它的SQL.我不知道目前的情况,但微软承诺将L2S的所有优点都迁移到L2EF中,所以也许现在一切都好了.

就个人而言,我的ORM工具一个充满激情的厌恶(见我的谩骂这里获取详细信息),所以我认为没有理由青睐L2EF,因为L2S了我的一切指望从数据访问层需要.事实上,我甚至认为手工制作的映射和继承建模等L2S功能增加了完全不必要的复杂性.但那只是我.;-)

Linq到EF已经成熟,现在生成的SQL和L2S一样好(从.NET 4.0开始).L2EF比L2S好很多,因为它至少可以在数据库更改时更新您的模型,而L2S永远不会自动执行.我也喜欢这样一个事实,你可以将简单的M:M关系映射到EF作为关系,而不需要有一个中间实体.它使代码更清晰. (3认同)
感谢@Dave的更新.不过,我不同意M:M的评论.我使用的模式几乎总是在连接表上增加额外的属性.这会导致对象模型的结构变化,需要大量的代码返工.我宁愿从一开始就明确地处理中间关系. (2认同)

归档时间：	15 年，4 月前
查看次数：	169340 次
最近记录：	6 年，1 月前