带有存储过程的实体框架 VS LINQ to SQL VS ADO.NET

首先，如果你要开始一个新项目，使用实体框架("EF")——它现在可以生成更好的SQL(更像Linq to SQL)，并且比Linq to SQL("L2S")更易于维护和更强大.在《纽约时报》发布之时.NET 4，我认为LINQ-SQL是过时的技术.MS对不再继续L2S开发持开放态度.

1) Performance

这很难回答.对于大多数单实体操作(CRUD)，您会发现这三种技术的性能几乎相当.您必须知道EF和Linq to SQL是如何工作的，才能充分利用它们.对于轮询查询之类的大容量操作，您可能希望EF/L2S"编译"实体查询，这样框架就不必不断地重新生成SQL，或者您可能会遇到可伸缩性问题.(见编辑)

对于更新大量数据的批量更新，原始SQL或存储过程的性能总是优于ORM解决方案，因为不必通过连接将数据封送到ORM来执行更新.

2) Speed of Development

在大多数情况下，当涉及到开发速度时，EF会将赤裸裸的SQL/存储过程一扫而光.EF designer可以在数据库发生更改时(根据请求)从数据库中更新模型，这样就不会在目标代码和数据库代码之间遇到同步问题.我唯一不考虑使用ORM的时候，是在做一个报告/仪表板类型的应用程序时，你没有做任何更新，或者当你创建一个应用程序只是在数据库上做原始数据维护操作.

3) Neat/Maintainable code

不言而喻，EF胜过SQL/sprocs.因为关系是建模的，所以代码中的连接相对较少.对于大多数查询，实体之间的关系几乎是不言而喻的.没有什么比必须进行层层调试或通过多个SQL/中间层来了解数据的实际情况更糟糕的了.EF以一种非常强大的方式将数据模型引入到代码中.

4) Flexibility

存储过程和原始SQL更"灵活".您可以利用存储过程和SQL为奇怪的特定情况生成更快的查询，并且可以比使用存储过程和ORM更容易地利用本机数据库功能.

5) Overall

Don't get caught up in the false dichotomy of choosing an ORM vs using stored procedures.您可以在同一个应用程序中同时使用这两种方法，而且您可能应该这样做.大批量操作应该放在存储过程或SQL(实际上可以由EF调用)中，EF应该用于CRUD操作和中间层的大部分需求.也许您会 Select 使用SQL编写报告.我猜这个故事的寓意和以往一样.使用正确的工具完成工作.但它的骨感是，EF现在非常好(从.NET4.0开始).花些时间深入阅读和理解它，你就可以轻松创建一些令人惊叹的高性能应用程序.

EDIT:EF 5用auto-compiled LINQ Queries简化了这一部分，但对于真正的大容量产品，你肯定需要测试和分析在现实世界中最适合你的产品.