在以下方面，你如何评价它们:
性能 发展速度 整洁、直观、可维护的代码 灵活性 整体
我喜欢我的SQL，所以一直是ADO的铁杆粉丝。NET和存储过程，但我最近玩了一个Linq to SQL，并被我写出我的DataAccess层的速度所震惊，并决定花一些时间真正理解Linq to SQL或EF…或不?
我只是想确认一下，这些技术中没有什么重大缺陷会让我的研究变得毫无用处。例如，性能很糟糕，对于简单的应用程序来说很酷，但只能到此为止。
更新: 你能专注于EF VS L2S VS SPs而不是ORM VS SPs吗?我主要对EF VS L2S感兴趣。但是我也热衷于将它们与存储的procs进行比较，因为纯SQl是我非常了解的东西。
当前回答
你的问题基本上是O/RM vs手写SQL
使用ORM还是普通SQL?
看看其他的O/RM解决方案，L2S并不是唯一的一个(NHibernate, ActiveRecord)
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
针对具体问题:
L2S非常擅长生成SQL，这取决于O/RM解决方案的质量 一旦了解了流程，使用O/RM通常会快得多 代码通常也更整洁，更易于维护 直接SQL当然会为您提供更大的灵活性，但大多数O/RM可以执行除最复杂的查询以外的所有查询 总的来说，我建议采用O/RM，灵活性损失可以忽略不计
其他回答
LINQ-to-SQL是一项出色的技术，使用起来非常简单，并且大体上可以生成非常好的后端查询。LINQ-to-EF本来打算取代它，但从历史上看，它的使用非常笨拙，生成的SQL也差得多。我不知道目前的情况，但是微软承诺将L2S的所有优点迁移到L2EF中，所以现在可能一切都好了。
就我个人而言，我非常不喜欢ORM工具(详见我的评论)，因此我认为没有理由支持L2EF，因为L2S为我提供了所有我期望从数据访问层获得的东西。事实上，我甚至认为L2S特性(如手工制作的映射和继承建模)增加了完全不必要的复杂性。但那只是我。: -)
存储过程:
(+)
极大的灵活性 完全控制SQL 最高的可用性能
(-)
需要SQL知识 存储过程不在源代码控制范围内 在指定相同的表和字段名时，大量的“重复自己”。在重命名一个DB实体并丢失对它的某些引用后，很可能会破坏应用程序。 缓慢的发展
ORM:
(+)
快速发展 数据访问代码现在在源代码控制下 您与DB中的更改隔离开来。如果发生这种情况，您只需要在一个地方更新您的模型/映射。
(-)
业绩可能会更差 没有或很少控制ORM生成的SQL(可能效率很低或bug更多)。可能需要进行干预并将其替换为自定义存储过程。这将使你的代码变得混乱(一些LINQ在代码中，一些SQL在代码中和/或在源代码控制之外的DB中)。 因为任何抽象都可能产生“高级”开发人员，他们根本不知道它是如何工作的
一般的权衡是在拥有很大的灵活性和损失大量时间与受到限制，但可以很快完成之间进行。
这个问题没有统一的答案。这是神圣的战争。这也取决于手头的项目和你的需求。选择最适合你的。
你的问题基本上是O/RM vs手写SQL
使用ORM还是普通SQL?
看看其他的O/RM解决方案，L2S并不是唯一的一个(NHibernate, ActiveRecord)
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
针对具体问题:
L2S非常擅长生成SQL，这取决于O/RM解决方案的质量 一旦了解了流程，使用O/RM通常会快得多 代码通常也更整洁，更易于维护 直接SQL当然会为您提供更大的灵活性，但大多数O/RM可以执行除最复杂的查询以外的所有查询 总的来说，我建议采用O/RM，灵活性损失可以忽略不计
首先，如果你正在开始一个新项目，使用实体框架(“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)发展速度
In most scenarios, EF will blow away naked SQL/stored procs when it comes to speed of development. The EF designer can update your model from your database as it changes (upon request), so you don't run into synchronization issues between your object code and your database code. The only time I would not consider using an ORM is when you're doing a reporting/dashboard type application where you aren't doing any updating, or when you're creating an application just to do raw data maintenance operations on a database.
3)整洁/可维护的代码
EF击败了SQL/sprocs。因为对关系进行了建模，所以代码中的连接相对较少。对于大多数查询，实体之间的关系对读者来说几乎是不言而喻的。没有什么比不得不从一层调试到另一层或通过多个SQL/中间层来了解数据实际发生了什么更糟糕的了。EF以一种非常强大的方式将数据模型引入到代码中。
4)灵活性
存储的proc和原始SQL更“灵活”。您可以利用spprocs和SQL为特定情况生成更快的查询，并且您可以比使用和ORM更容易地利用本机DB功能。
5)整体
Don't get caught up in the false dichotomy of choosing an ORM vs using stored procedures. You can use both in the same application, and you probably should. Big bulk operations should go in stored procedures or SQL (which can actually be called by the EF), and EF should be used for your CRUD operations and most of your middle-tier's needs. Perhaps you'd choose to use SQL for writing your reports. I guess the moral of the story is the same as it's always been. Use the right tool for the job. But the skinny of it is, EF is very good nowadays (as of .NET 4.0). Spend some real time reading and understanding it in depth and you can create some amazing, high-performance apps with ease.
编辑:EF 5使用自动编译的LINQ查询简化了这一部分，但对于真正的高容量的东西，你肯定需要测试和分析在现实世界中最适合你的东西。
如果您追求的是存储过程的功能和性能，以及Entity Framework等工具提供的快速开发，那么您可能需要考虑一种全新的方法。
我已经在一个小项目上进行了SQL+的测试，它真的很特别。基本上，您可以向SQL例程添加相当于注释的内容，这些注释向代码生成器提供指令，然后代码生成器根据实际的SQL例程构建一个非常好的面向对象类库。有点像反向的实体框架。
输入参数成为输入对象的一部分，输出参数和结果集成为输出对象的一部分，服务组件提供方法调用。
如果您希望使用存储过程，但仍然希望快速开发，那么您可能需要看看这些东西。
