存储过程：

(+)

• 具有很大的灵活性
• 完全控制 SQL
• 可用性能最高

(-)

• 需要了解 SQL
• 存储过程未在源代码控制下
• 在指定相同的表和字段名称时需要大量的“重复自己”的工作。重命名数据库实体后可能会有高概率的破坏应用程序，因为可能遗漏了对其的一些引用。
• 开发速度较慢

ORM（对象关系映射）：

(+)

• 快速开发
• 数据访问代码现在在源代码控制下
• 您与 DB 的变化相隔一段距离。如果发生这种情况，您只需要在一个地方更新您的模型/映射。

(-)

• 性能可能更差
• 对 ORM 产生的 SQL 没有或几乎没有控制权（可能效率低下或更糟糕的错误）。可能需要介入并将其替换为自定义存储过程。这将使您的代码混乱（一些 LINQ 在代码中，一些 SQL 在代码和/或未在源代码控件中的 DB 中）。
• 任何抽象化都可能产生“高级”开发人员不知道它在引擎盖下如何工作

一般的权衡是在拥有很大的灵活性和失去很多时间之间进行选择，与在你能做什么方面有所限制，但能迅速完成之间进行选择。

这个问题没有通用的答案。这是一场圣战的问题。也取决于手头的项目以及您的需求。选取最适合您的。

首先，如果你要开始一个新项目，使用Entity Framework（“EF”）- 现在它生成的SQL更好（像Linq to SQL）并且比Linq to SQL（“L2S”）更易于维护和更强大。自发布.NET 4.0以来，我认为Linq to SQL是一种过时的技术。微软一直非常坦率地表示不会进一步开发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更容易利用原生的数据库功能。

5）总体

不要陷入选择ORM与使用存储过程的虚假二分法中。你可以在同一个应用程序中同时使用两者，你可能应该这样做。大量操作应该放在存储过程或SQL中（实际上可以由EF调用），EF应该用于CRUD操作和大多数中间层的需要。也许您会选择使用SQL来编写报告。我想故事的教训和以前一样：使用适合工作的正确工具。但是EF现在很好（自.NET 4.0以来）。花些时间深入阅读和理解，您可以轻松创建一些惊人的，高性能的应用程序。

编辑：EF 5通过自动编译的LINQ查询简化了这个部分，但对于实际的大容量处理，你肯定需要测试和分析哪种方法适合你。