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

你会如何评价每个：

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是我所了解的不少东西。

---

#1楼

LINQ-to-SQL是一项很是出色的技术，使用起来很是简单，而且整体上会为后端生成很是好的查询。 LINQ-to-EF计划取代它，但历史上一直很是笨拙地使用并生成了远低于它的SQL。 我不知道目前的状况，但微软承诺将L2S的全部优势都迁移到L2EF中，因此也许如今一切都好了。

就我的而言，个人ORM工具一个充满激情的厌恶（见个人谩骂这里获取详细信息），因此我认为没有理由青睐L2EF，由于L2S了个人一切期望从数据访问层须要。 事实上，我甚至认为手工制做的映射和继承建模等L2S功能增长了彻底没必要要的复杂性。 但那只是我。 ;-)

---

#2楼

存储过程：

（+）

• 灵活性极大
• 彻底控制SQL
• 可用的最高性能

（ - ）

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

ORM：

（+）

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

（ - ）

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

---

通常的权衡是在具备很大的灵活性和失去大量时间与限制你能够作的事情之间，但要快速完成。

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

---

#3楼

你的问题基本上是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. Straight SQL固然会为您提供更大的灵活性，但大多数O / RM能够完成除最复杂查询以外的全部操做
5. 总的来讲，我建议使用O / RM，灵活性损失能够忽略不计

---

#4楼

首先，若是您正在开始一个新项目，请使用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查询简化了这一部分，可是对于真正的高容量，你确定须要测试和分析在现实世界中最适合你的东西。

---

#5楼

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

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

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

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