实体框架VS LINQ to SQL VS ADO.NET与存储过程？
你如何评价他们每个人的方面：
我喜欢我的SQL，因此一直都是ADO.NET和存储过程的忠实拥趸，但是我最近和Linq to SQL一起玩过，并且被我写出DataAccess图层并决定花钱的速度吓到了。有些时候真正理解Linq to SQL或者EF ...或者两者都不是？
我只是想检查一下，这些技术中没有任何一个缺陷会使我的研究时间毫无用处。 例如，性能很差，对于简单的应用来说很酷，但只能带你到目前为止。
更新：您可以专注于EF VS L2S VS SP，而不是ORM VS SP。 我主要感兴趣的是EF VS L2S。 但我急于让他们与存储过程进行比较，因为SQl是我知道的很多东西。
首先，如果你开始一个新项目，使用实体框架（“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和ORM更轻松地利用本机数据库功能。
5）总体
不要陷入选择ORM与使用存储过程的错误二分法。 您可以在同一个应用程序中使用两者，而且您可能应该这样做。 大批量操作应该使用存储过程或SQL（实际上可以由EF调用），EF应该用于CRUD操作和大部分中间层需求。 也许你会选择使用SQL来编写报告。 我想这个故事的寓意与以往一样。 使用正确的工具来完成这项工作。 但它的骨感是，现在EF非常好（从.NET 4.0开始）。 花点时间阅读并深入理解它，并且可以轻松创建一些令人惊叹的高性能应用程序。
编辑 ：EF 5使用自动编译的LINQ Queries简化了这一部分，但对于真正的高容量的东西，您一定需要测试和分析在现实世界中最适合您的东西。
存储过程：
（++）
（ - ）
ORM：
（+）
（ - ）
一般的权衡取决于具有很大的灵活性和失去很多时间，而不是限制在你能做的事情上，而是让它很快完成。
这个问题没有一般的答案。 这是圣战的问题。 还取决于手头的项目和您的需求。 拿起最适合你的东西。
你的问题基本上是O / RM的vs手写SQL
使用ORM还是纯SQL？
看看其他一些O / RM解决方案，L2S不是唯一的（NHibernate，ActiveRecord）
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
解决具体问题：
上一篇: Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures?