LINQ 相对于存储过程的一些优点：

1. 类型安全 ：我想我们都明白这一点。
2. 抽象：对于 LINQ-to-Entities尤其如此。这种抽象还允许框架添加您可以轻松利用的其他改进。 PLINQ是向 LINQ 添加多线程支持的示例。添加此支持的代码更改很少。执行这种仅调用 sprocs 的数据访问代码会困难得多。
3. 调试支持 ：我可以使用任何 .NET 调试器来调试查询。使用存储过程，您无法轻松地调试 SQL，并且这种体验很大程度上取决于您的数据库供应商（MS SQL Server 提供了一个查询分析器，但通常这还不够）。
4. 供应商不可知论 ：LINQ 可与大量数据库一起使用，支持的数据库数量只会增加。由于不同的语法或功能支持（如果数据库完全支持 sprocs），Sprocs 并不总是在数据库之间可移植。
5. 部署 ：其他人已经提到了这一点，但是部署单个程序集比部署一组存储过程更容易。这也与#4 相关。
6. 更简单 ：您不必学习 T-SQL 来进行数据访问，也不必学习调用存储过程所需的数据访问 API（例如 ADO.NET）。这与#3 和#4 有关。

LINQ vs sprocs 的一些缺点：

1. 网络流量 ：当 LINQ 发送整个查询时，sprocs 只需要通过线路序列化 sproc-name 和参数数据。如果查询非常复杂，这可能会变得非常糟糕。然而，LINQ 的抽象允许微软随着时间的推移改进这一点。
2. 不太灵活 ：Sprocs 可以充分利用数据库的功能集。LINQ 的支持往往更通用。这在任何类型的语言抽象中都很常见（例如 C# 与汇编程序）。
3. 重新编译 ：如果需要更改数据访问方式，则需要重新编译、版本化和重新部署程序集。Sprocs 有时 可以让 DBA 调整数据访问例程，而无需重新部署任何东西。

安全性和可管理性也是人们争论的话题。

1. 安全性 ：例如，您可以通过直接限制对表的访问来保护您的敏感数据，并将 ACL 放在存储过程中。但是，使用 LINQ，您仍然可以限制对表的直接访问，而是将 ACL 放在可更新的表 视图 上以达到类似的目的（假设您的数据库支持可更新的视图）。
2. 可管理性 ：使用视图还可以使您的应用程序不受模式更改的影响（如表规范化）。您可以更新视图，而无需更改数据访问代码。

我曾经是一个大 sproc 人，但我开始倾向于将 LINQ 作为一个更好的选择。如果在某些领域存储过程明显更好，那么我可能仍会编写存储过程，但使用 LINQ
访问它。:)