entity frameworkVS LINQ to SQL VS ADO.NET与存储过程？
你如何评价他们每个人的方面：
- 性能
- 发展速度
- 整洁，直观，可维护的代码
- 灵活性
- 总体
我喜欢我的SQL，所以一直是ADO.NET和存储过程的忠实拥趸，但是我最近和Linq to SQL玩了一阵子，被我写了DataAccess层的速度吓了一跳，决定花钱有一段时间，真正理解Linq到SQL或EF …或者都不是？
我只是想检查一下，这些技术没有太大的缺陷，会使我的研究时间毫无用处。 例如，性能很糟糕，简单的应用程序很酷，但只能带你到目前为止。
更新：您可以专注于EF VS L2S VS SP，而不是ORM VS SP。 我主要感兴趣的是EF VS L2S。 但是我也热衷于将它们与存储过程进行比较，因为SQl是我知道的很多东西。
首先，如果你正在开始一个新项目，使用entity framework（“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解决scheme执行得更好，因为您不必通过线路将数据封送到ORM以执行更新。
2）发展速度
在大多数情况下，当涉及到开发速度的时候，EF将会吹走裸SQL /存储过程。 EFdevise人员可以在您的数据库更新（根据请求）更新您的模型，因此您不会遇到目标代码和数据库代码之间的同步问题。 我唯一不考虑使用ORM的方法是，当你正在做一个报告/仪表盘types的应用程序时，你没有进行任何更新，或者当你创build一个应用程序来做一个数据库的原始数据维护操作。
3）整洁/可维护的代码
放手，EF击败SQL / sprocs。 因为你的关系是build模的，所以你的代码中的连接相对来说比较less见。 对于大多数查询来说，实体之间的关系对于读者来说几乎是不言而喻的。 没有什么比从一层到另一层的debugging或者通过多个SQL /中间层去理解实际发生在你的数据上的事情更糟。 EF将您的数据模型以非常强大的方式带入您的代码。
4）灵活性
存储过程和原始SQL更“灵活”。 您可以利用sprocs和SQL为奇怪的特定情况生成更快的查询，并且可以比使用ORM更容易地利用本机数据库function。
5）整体
不要陷入selectORM与使用存储过程的错误二分法 。 你可以在同一个应用程序中使用两者，你可能应该这样做。 大批量操作应该存储在存储过程或SQL中（实际上可以由EF调用），EF应该用于CRUD操作和大部分中间层需求。 也许你会select使用SQL来编写报告。 我想这个故事的道德是一贯的。 使用正确的工具来完成这项工作。 但是它的骨感是，EF现在非常好（从.NET 4.0开始）。 花点时间阅读并深入理解它，您可以轻松创build一些令人惊叹的高性能应用程序。
编辑 ：EF 5 自动编译的LINQ查询简化了这个部分，但是对于真正的高容量的东西，你一定要testing和分析什么最适合你在现实世界中。
存储过程：
（++）
- 极大的灵活性
- 完全控制SQL
- 可用的最高性能
（ – ）
- 需要了解SQL
- 存储过程不受源代码控制
- 在指定相同的表格和字段名称时，大量的“重复自己”。 重命名数据库实体并在某处丢失对其的某些引用之后破坏应用程序的高可能性。
- 发展缓慢
ORM：
（+）
- 快速发展
- 数据访问代码现在在源代码控制下
- 您与数据库中的更改隔离。 如果发生这种情况，你只需要在一个地方更新你的模型/映射。
（ – ）
- 性能可能会更糟
- 对ORM产生的SQL没有或很less的控制（可能是低效率或更糟糕的bug）。 可能需要介入并用自定义的存储过程replace它。 这会使你的代码变得混乱（某些代码中的LINQ，代码中的一些SQL和/或源代码pipe理中的数据库中）。
- 因为任何抽象都可能产生“高层次”的开发人员，他们不知道它是如何工作的
一般的权衡是有很大的灵活性和损失很多的时间与限制在你能做的事情之间，但它做得非常快。
这个问题没有一般的答案。 这是圣战的问题。 还取决于一个项目和你的需求。 拿起最适合你的东西。
你的问题基本上是O / RM的vs手写SQL
使用ORM或纯SQL？
看看其他一些O / RM解决scheme，L2S不是唯一的（NHibernate，ActiveRecord）
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
解决具体问题：
- 取决于O / RM解决scheme的质量，L2S在生成SQL方面非常出色
- 一旦你了解了这个过程，使用O / RM通常会快得多
- 代码通常也更整洁，更易于维护
- 直接的SQL当然会给你更多的灵活性，但是大多数O / RM可以完成除最复杂的查询以外的所有操作
- 总的来说，我会build议与O / RM，灵活性损失是可以忽略的
LINQ到SQL是一个非常简单易用的技术，总的来说，它可以为后端生成非常好的查询。 LINQ到EF的定义是取代它，但历史上使用和生成非常低劣的SQL非常笨重。 我不知道目前的情况，但微软承诺把L2S的所有优点都转移到L2EF上，所以现在好了。
就我个人而言，我对ORM工具充满了厌恶（见我的谩骂细节），所以我没有理由去支持L2EF，因为L2S给了我所有我期望从数据访问层得到的所有东西。 实际上，我甚至认为手工映射和inheritancebuild模等L2S特性增加了完全不必要的复杂性。 但那只是我。 😉
