实体框架VS LINQ to SQL VS ADO.NET具有存储过程吗？[关闭]

430

您如何按照以下方式对每个人进行评分：

  1. 性能
  2. 发展速度
  3. 简洁，直观，可维护的代码
  4. 灵活性
  5. 总体

我喜欢我的SQL，因此一直是ADO.NET和存储过程的忠实拥护者，但是最近我对Linq to SQL玩了些，对我写DataAccess层的速度感到震惊，并决定花费有一段时间真的了解Linq to SQL或EF ...还是都不了解？

我只想检查一下，这些技术中没有什么会导致我的研究时间毫无用处的重大缺陷。例如，性能太差了，对于简单的应用程序来说这很酷，但只能带您走远。

更新： 您能否专注于EF VS L2S VS SP而不是ORM VS SP。我主要对EF VS L2S感兴趣。但是我也很想将它们与存储的proc进行比较，因为我很了解纯SQl。

sql  linq-to-sql  entity-framework  ado.net  linq-to-entities 
— 英国开发商
source
94
不是建设性的，但有很多支持吗？...;）
— BritishDeveloper 2012年
34
我不明白为什么有人将其标记为非建设性的。对我来说真的很好。向我+1。
— Thanushka
10
我认为这是一个很好的问题。就个人而言，我注意到实体框架和所有类似的ORM都比纯/简单的ADO.Net代码慢。我在2年前进行了这项测试，然后又在一周前进行了测试。我不确定LINQ to SQL与EF的比较。但是ADO.Net将永远是性能最好的。如果您想节省开发时间，那么Entity Framework是一个不错的工具，但绝对不是您最关心的性能问题。
— Sunil
2
@Timeless：有一种趋势是不依赖数据库机制。每个数据库引擎都有其自己的存储过程语言，因此需要额外的学习。99.9％的开发人员可以依靠ORM，后者会生成非常好的代码并自动创建SQL。对于简单的CRUD，性能差异很小。存储过程很难开发和维护。几年前，当没有ORM时，数据库无法神奇地自动生成任何内容。认为编写SP并不那么耗时，因为它可以替代在应用程序中编写SQL语句。
— LukLed 2014年
4
@Sunil是正确的，尽管不够罗word。问题是每个人都认为他们的主要关注点是应用程序性能。当我谈论需要最高性能的应用程序时，我想到的是核心C ++ MMO或成千上万的面向客户的大量数据库事务。您确实应该专注于面向对象的原则，例如可维护性，可读性，持久性无知和域逻辑分离。特别是在许多情况下，性能提升很少达到最佳状态或根本不存在时。
— Suamere 2014年

Answers:

430

首先，如果您要开始一个新项目，请使用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 / sproc。因为您的关系是建模的，所以在您的代码中加入联接的频率相对较低。对于大多数查询，实体的关系对于读者几乎是不言而喻的。为了理解数据实际发生的事情，没有比进行层级调试或通过多个SQL /中间层更糟糕的事情了。EF以非常强大的方式将数据模型带入代码中。

4）灵活性

存储的proc和原始SQL更“灵活”。您可以利用sproc和SQL来为奇特的特定情况生成更快的查询，并且可以比使用ORM更轻松地利用本机数据库功能。

5）总体

不要陷入选择ORM与使用存储过程的错误二分法中。 您可以在同一应用程序中使用它们，也许应该。大批量操作应在存储过程或SQL（可以由EF实际调用）中进行，并且EF应该用于CRUD操作和大多数中间层需求。也许您会选择使用SQL编写报告。我想这个故事的寓意和以往一样。使用正确的工具完成工作。但是它很肤浅，如今，EF非常好（从.NET 4.0开始）。花一些实时阅读和深入了解它，您可以轻松创建一些出色的高性能应用程序。

编辑：EF 5通过自动编译的LINQ查询简化了这一部分，但是对于真正的大批量产品，您肯定需要测试和分析在现实世界中最适合您的东西。

— 戴夫·马克尔
source
35
绝对出色的答案。我现在确实在使用EF来快速开发应用程序。如果性能成为问题，则将使用存储的proc来重构性能不佳的EF查询。谢谢！
— BritishDeveloper 2010年
17
@BritishDeveloper：另外，也不要忘记使用视图的强大功能。我们在L2S项目中定义了几个视图，并在框架似乎编写糟糕查询的地方利用它们，取得了巨大的成功。这样，我们获得了使用框架的所有好处以及编写我们自己的SQL的所有好处。
— 戴夫·马克尔2010年
5
我也使用Views;）来解决EF的非跨数据库限制。虽然是用于优化的好主意。谢谢
— BritishDeveloper
5
绝对是一个很好的回应。只是想补充一下我在L2S vs EF4方面的经验。在意识到我们可能正在使用几个不同的RDMBS之后，从L2S-> EF4进行了交换...但是，尽管仍在运行MSSQL，性能下降主要表现在我的应用程序的GUI区域。在L2S中与结果集的数据绑定比EF4快得多。在完全相同的数据库上完全相同的查询。不过，这里要注意的一件事是我要返回90k +记录，因此区别非常明显。也许在较小的布景上不是问题吗？不知道如何在高
— 流量
5
反应良好。我刚刚花了4周的时间与LINQ-to-Entities进行合作，试图将所有内容塞入其中，最后才意识到您需要本机SQL来进行诸如批量复制，批量删除，从数据库中快速删除重复项之类的工作。这项工作的正确工具，将本地SQL与LINQ to Entities框架混合在一起不会感到羞耻。
— Contango 2011年
93

存储过程：

（+）

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

（-）

  • 需要SQL知识
  • 存储过程不受源代码控制
  • 指定相同的表和字段名称时需要大量的“重复自己”。重命名数据库实体并在某些地方缺少对该应用程序的引用后，有很大的机会破坏应用程序。
  • 发展缓慢

ORM：

（+）

  • 快速发展
  • 数据访问代码现在处于源代码控制之下
  • 您与数据库中的更改隔离。如果发生这种情况，您只需要在一个地方更新模型/映射即可。

（-）

  • 性能可能更差
  • 对ORM产生的SQL的控制很少或很少（可能效率低下，甚至可能造成错误）。可能需要干预并将其替换为自定义存储过程。这会使您的代码混乱（一些LINQ代码，一些SQL代码和/或数据库中的源代码控制）。
  • 因为任何抽象都可以产生“高级”开发人员，却不知道其幕后工作方式

一般的权衡是在具有很大的灵活性和浪费大量时间之间，而不是在可以做的事情上受限制，但要很快完成。

这个问题没有普遍的答案。这是一场圣战。还取决于手头的项目和您的需求。挑选最适合您的东西。

— AGuyCalledGerald
source
47
我认为关于源代码控制的要点无关紧要。数据库模式，存储过程，UDF等都可以并且应该在源代码控制之下。
— 李·冈恩
15
+1 forAs any abstraction can produce "high-level" developers having no idea how it works under the hood
— nawfal 2012年
3
同意，源代码控制参数不正确。我们始终将数据库创建脚本存储在svn中。开发数据库应用程序时，如何甚至将数据库保持在源代码控制之外？
— Wout 2012年
3
EF并不是真正适合于高可用性和高性能，我不是DBA专家，但是我看不到EF提供了什么，这使得编写代码变得更加容易。
— 杰米
4
因此，我们放弃了“快速开发”的灵活性，完全控制权和性能，并且避免了数据库更改时代码的更改。对我来说听起来像是完全懒惰。
— user2966445
18

您的问题基本上是O / RM与手写SQL

使用的是ORM还是纯SQL？

看一下其他一些O / RM解决方案，L2S并不是唯一的解决方案（NHibernate，ActiveRecord）

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

解决具体问题：

  1. 取决于O / RM解决方案的质量，L2S非常擅长生成SQL
  2. 一旦完成该过程，使用O / RM通常会更快
  3. 代码通常也更整洁和更易于维护
  4. 直截了当的SQL当然可以为您提供更大的灵活性，但是大多数O / RM可以完成除最复杂的查询之外的所有查询
  5. 总的来说，我建议使用O / RM，灵活性损失可以忽略不计
— 黑冰
source
@David谢谢，但是不是ORM vs SQL。我想转到ORM，并且想知道应该花些时间在学习上：EF或L2S（除非与Stored
— Procs
1
与存储的proc相比，我绝对会说它们不是垃圾，而且附带的好处是您无需将代码传播到数据库。我个人比较喜欢L2S，但是到那时我还没有对EF做很多事情，而且看来L2EF将会取代它，所以我会选择EF。另外，一旦您进入Linq，就不会再返回。
— BlackICE 2010年
13

LINQ-to-SQL是一项非凡的技术，它非常易于使用，并且总的来说会向后端生成非常好的查询。LINQ-to-EF原本打算取代它，但是从历史上看，它使用起来非常笨拙，并且生成了劣等的SQL。我不知道当前的状况，但是微软承诺将L2S的所有优点都迁移到L2EF中，所以现在情况可能会更好。

就我个人而言，我非常讨厌ORM工具（有关详细信息，请参见此处的详细信息），因此我认为没有理由支持L2EF，因为L2S满足了我从数据访问层获得的所有期望。实际上，我什至认为手工制作的映射和继承建模等L2S功能会增加完全不必要的复杂性。但这就是我。;-)

— 马塞洛·坎托斯（Marcelo Cantos）
source
1
L2S相当不错，但是有一个缺点，即微软已经表示，他们基本上不会在扩展它方面投入太多资金。您可以在最新版本中看到其结果，该最新版本仅修复了一些错误，并添加了对SQL Server 2008数据类型的支持。
— FinnNk 2010年
同意@FinnNk。不幸的现实是，由于L2S的贱民身份，使用它有些冒险。但是，如果他们真的完全放弃了L2EF的支持，我强烈怀疑会有一条迁移之路，因为它仍然很受欢迎。
— Marcelo Cantos
3
Linq to EF已经成熟，现在可以产生与L2S一样好的SQL（从.NET 4.0开始）。如今，L2EF比L2S好很多，因为它至少可以随着数据库的更改而更新您的模型，而L2S永远不会自动进行更新。我也喜欢这样的事实，您可以将带有EF的简单M：M关系映射为关系，而无需中间实体。它使代码更整洁。
— 戴夫·马克尔
2
感谢更新@Dave。但是，我不同意M：M的评论。我使用的模式几乎总是在联接表上增加额外的属性。这引起了对象模型的结构变化，需要大量的代码重做。我宁愿从一开始就明确地处理中间关系。
— Marcelo Cantos
1

您可能需要考虑一种全新的方法，即存储过程的功能和性能以及诸如Entity Framework之类的工具所提供的快速开发功能。

我已经将SQL +用于一个小项目的测试驱动器，这确实很特别。您基本上在SQL例程中添加了相当于注释的内容，这些注释为代码生成器提供了指令，然后代码生成器会基于实际的SQL例程构建一个非常好的面向对象的类库。有点像相反的实体框架。

输入参数成为输入对象的一部分，输出参数和结果集成为输出对象的一部分，并且服务组件提供方法调用。

如果您想使用存储过程，但仍希望快速开发，则可能需要看看这些内容。

— 文森特
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.