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

Question

你会如何评价每一个：

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感兴趣。但我很想将它们与存储过程进行比较，因为普通的SQl是我所了解的很多东西。

Answer 1

首先，如果您正在开始一个新项目，请使用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使用auto-compiled LINQ Queries简化了这一部分，但对于真正的高容量，你肯定需要测试和分析在现实世界中最适合你的东西。

Answer 2

存储过程：

(+)

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

(-)

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

ORM：

(+)

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

(-)

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

---

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

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

Answer 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

解决具体问题：

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

Answer 4

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

就个人而言，我对ORM工具充满热情（详见我的diatribe here），所以我认为没有理由支持L2EF，因为L2S给了我所有我期望从数据访问层获得的东西。事实上，我甚至认为手工制作的映射和继承建模等L2S功能增加了完全不必要的复杂性。但那只是我。 ;-)

Answer 5

如果你所追求的是存储过程的强大功能和性能，以及像Entity Framework这样的工具所提供的快速开发，那么你可能需要考虑一种全新的方法。

我已经在一个小项目中使用SQL +进行试驾，这真的很特别。您基本上向SQL例程添加了多少注释，这些注释为代码生成器提供了指令，然后代码生成器根据实际的SQL例程构建一个非常好的面向对象的类库。有点像反向的实体框架。

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

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