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

Posted 2023-02-16

【中文标题】带有存储过程的实体框架 VS LINQ to SQL VS ADO.NET？ [关闭]

【英文标题】：Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures? [closed]

【发布时间】：2011-02-11 11:49:38

【问题描述】：

你如何评价他们每个人：

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

我喜欢我的 SQL，因此一直是 ADO.NET 和存储过程的铁杆粉丝，但我最近玩了 Linq to SQL，被我写出 DataAccess 层的速度之快震惊了决定花一些时间真正了解 Linq to SQL 或 EF……还是两者都不了解？

我只是想检查一下，这些技术中没有任何重大缺陷会导致我的研究时间毫无用处。例如。性能很糟糕，对于简单的应用程序来说很酷，但只能带你到这么远。

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

【问题讨论】：

没有建设性，但有这么多赞成？... ;)

我不明白为什么有人将其标记为不具建设性。这对我来说似乎真的很好。来自我的 +1。

在我看来这是一个很好的问题。就个人而言，我注意到实体框架和所有类似的 ORM 与普通/简单的 ADO.Net 代码相比要慢一些。两年前我做了这个测试，然后一周前又做了一次。我不确定 LINQ to SQL 与 EF 相比如何。但 ADO.Net 将永远是性能最好的。如果您想节省开发时间，那么 Entity Framework 是一个很好的工具，但绝对不是当您最关心性能时。

@Sunil 是正确的，虽然不够罗嗦。问题是每个人都认为他们最关心的是应用性能。当我谈到需要***性能的应用程序时，我会想到核心 C++ MMO 或数百万的面向客户的大容量数据库事务。你真的应该关注面向对象的原则，例如可维护性、可读性、持久性无知和领域逻辑分离。尤其是在很多情况下，性能提升很少或根本不存在。

这个问题对我很有用。这是一个建设性的问题，可能会提供非常有用的信息。 *** 社区也不应该认为这是我的没有建设性 +1。

【参考方案1】：

首先，如果您要开始一个新项目，请使用实体框架（“EF”）——它现在生成更好的 SQL（更像 Linq to SQL 所做的），并且比 Linq to 更容易维护和更强大SQL（“L2S”）。在 .NET 4.0 发布时，我认为 Linq to SQL 是一种过时的技术。 MS 对不再继续 L2S 开发持非常开放的态度。

1) 性能

这很难回答。对于大多数单实体操作 (CRUD)，您会发现这三种技术的性能几乎相同。您必须了解 EF 和 Linq to SQL 的工作原理才能充分利用它们。对于轮询查询等大容量操作，您可能希望 EF/L2S “编译”您的实体查询，这样框架就不必不断地重新生成 SQL，否则您可能会遇到可伸缩性问题。 （见编辑）

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

2) 发展速度

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

3) 整洁/可维护的代码

毫无疑问，EF 击败了 SQL/sprocs。因为您的关系是建模的，所以代码中的连接相对较少。对于大多数查询，实体的关系对读者来说几乎是不言而喻的。没有什么比不得不逐层调试或通过多个 SQL/中间层来了解数据实际发生的情况更糟糕的了。 EF 以一种非常强大的方式将您的数据模型带入您的代码中。

4) 灵活性

存储过程和原始 SQL 更加“灵活”。您可以利用 sprocs 和 SQL 为奇怪的特定情况生成更快的查询，并且您可以比使用 ORM 更容易地利用本机 DB 功能。

5) 总体

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

编辑：EF 5 使用auto-compiled LINQ Queries 稍微简化了这部分，但对于真正的高容量内容，您肯定需要测试和分析最适合您在现实世界中的内容。

【讨论】：

绝妙的答案。我现在确实在使用 EF 来快速开发应用程序。如果性能成为问题，将引入存储过程来重构性能不佳的 EF 查询。谢谢！

@BritishDeveloper：另外，不要忘记使用视图的强大功能。我们在 L2S 项目中定义了几个视图并在框架似乎编写不佳查询的地方利用它们取得了巨大的成功。这样一来，我们就可以享受到使用该框架的所有好处以及编写自己的 SQL 的所有好处。

我也在使用 Views ;) 更多是为了解决 EF 的非跨数据库限制。不过，用于优化的好主意。谢谢

绝对是一个很好的回应。只是想补充一下我在 L2S 与 EF4 方面的经验。在我们意识到我们可能正在使用几个不同的 RDMBS 之后，从 L2S -> EF4 交换......但是，在仍然运行 MSSQL 时，性能下降主要表现在我的应用程序的 GUI 区域。 L2S 中结果集的数据绑定比 EF4 快得多。这是在完全相同的数据库上完全相同的查询。不过这里要注意的一件事是我返回了 90k+ 条记录，因此差异非常明显。也许在较小的集合上这不是问题？不知道它会如何扩展高容量网站......

良好的反应。我刚刚花了 4 周的时间使用 LINQ-to-Entities，试图将所有内容都塞进去，然后才最终意识到您需要本机 SQL 来进行批量复制、批量删除、从数据库中超快速删除重复项等。使用适合这项工作的工具，将本机 SQL 与 LINQ to Entities 框架混合并不可耻。

【参考方案2】：

存储过程：

(+)

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

(-)

需要 SQL 知识 存储过程不受源代码控制 大量“重复自己”，同时指定相同的表和字段名称。重命名数据库实体并在某处丢失对它的一些引用后破坏应用程序的可能性很高。 发展缓慢

ORM：

(+)

快速发展 数据访问代码现在受源代码控制 您与数据库中的更改隔离。如果发生这种情况，您只需在一处更新您的模型/映射。

(-)

性能可能会更差 对 ORM 生成的 SQL 没有或很少控制（可能效率低下或更糟糕的错误）。可能需要干预并用自定义存储过程替换它。这将使您的代码变得混乱（代码中的一些 LINQ、代码中的一些 SQL 和/或数据库中的源代码控制）。 因为任何抽象都可能导致“高级”开发人员不知道它是如何工作的

---

一般的权衡是在拥有很大的灵活性和浪费大量时间与受限于您可以做的事情但很快完成之间。

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

【讨论】：

我不认为关于源代码控制的要点是相关的。数据库架构、存储过程、UDF 等都可以并且应该受到源代码控制。

+1 As any abstraction can produce "high-level" developers having no idea how it works under the hood

同意，源代码管理参数不正确。我们总是将我们的数据库创建脚本存储在 svn 中。在开发数据库应用程序时，如何将数据库置于源代码控制之外？

EF 并不真正适合高可用性和高性能，我不是 DBA 人，但我看不出 EF 提供了什么让编码更容易。

因此，我们放弃了“快速开发”的灵活性、完全控制和性能，并在数据库更改时避免代码更改。对我来说听起来像是纯粹的懒惰。

【参考方案3】：

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

Using an ORM or plain SQL?

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

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

解决具体问题：

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

【讨论】：

@David 谢谢，但它不是 ORM 与 SQL。我正在寻找转向 ORM 并且想知道在学习上投入时间：EF 或 L2S（除非它们与存储过程相比是垃圾）

我肯定会说它们与存储过程相比并不垃圾，而且还有一个好处是您没有将代码传播到数据库。就我个人而言，我喜欢 L2S，但目前我还没有对 EF 做太多事情，而且 L2EF 似乎会取代它，所以我会选择 EF。另外，一旦你去 Linq，你就不会回去了。

【参考方案4】：

LINQ-to-SQL 是一项了不起的技术，它使用起来非常简单，而且总的来说可以为后端生成非常好的查询。 LINQ-to-EF 计划取代它，但从历史上看，它使用起来非常笨拙，并且生成的 SQL 也差得多。我不知道目前的情况，但微软承诺将 L2S 的所有优点迁移到 L2EF 中，所以现在也许一切都好起来了。

就个人而言，我非常不喜欢 ORM 工具（有关详细信息，请参阅我的 diatribe here），因此我认为没有理由支持 L2EF，因为 L2S 为我提供了数据访问层所需的一切.事实上，我什至认为手工映射和继承建模等 L2S 特性完全增加了不必要的复杂性。但这只是我。 ;-)

【讨论】：

L2S 相当不错，但缺点是微软已经表示他们基本上不会在扩展上投入太多资金。您可以在最新版本中看到这一结果，该版本仅修复了一些错误并添加了对 SQL Server 2008 数据类型的一些支持。

同意，@FinnNk。不幸的现实是，由于 L2S 的贱民地位，使用 L2S 存在一定的风险。但如果他们真的完全支持 L2EF，我强烈怀疑会有一条迁移路径，因为它仍然喜欢以下内容。

Linq to EF 已经成熟，现在生成的 SQL 与 L2S 一样好（从 .NET 4.0 开始）。 L2EF 现在比 L2S 好很多，因为它至少可以随着数据库的变化更新你的模型，而 L2S 永远无法自动完成。我还喜欢这样一个事实，即您可以将简单的 M:M 关系与 EF 映射为关系，而无需使用中间实体。它使代码更加简洁。

感谢@Dave 的更新。但是，我不同意 M:M 的评论。我使用过的模式几乎总是在连接表上增加额外的属性。这会导致对象模型的结构发生变化，需要大量的代码返工。我宁愿从一开始就明确地处理中间关系。

【参考方案5】：

如果您追求的是存储过程的功能和性能，以及 Entity Framework 等工具提供的快速开发，您可能需要考虑一种全新的方法。

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

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

如果你想使用存储过程，但仍然想快速开发，你可能想看看这个东西。