实体框架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更容易维护和更强大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例程构建一个非常好的面向对象的类库。倒是有点像实体框架。

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

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