我在其他答案中没有发现的一点是:

如果在您的环境中，数据库及其模式是体系结构的核心，应用程序的作用更小，那么更多地使用存储过程可能是有意义的，这可能有助于为所有需要访问DB的应用程序提供一个级别基础，从而减少代码重复(例如，您确定所有访问DB的应用程序都是用c#或其他。net语言编写的吗?)

另一方面，如果应用程序具有更核心的角色，而DB更多地充当应用程序的备份存储，那么减少存储过程的使用并通过提供一个公共持久性层(可能基于ORM工具/框架)来减少代码重复可能是明智的。

在这两种情况下，重要的是不要将DB视为存储过程的方便存储库。将它们保存在版本控制系统的源文件中，并尽可能地尝试自动化它们的部署(这实际上对所有与模式相关的构件都有效)。

我参加的Microsoft TechEd安全会议的建议之一是，通过存储过程进行所有调用，并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做，但如果您已经在使用存储过程，那么这样做也无妨。

存储过程的优先级，因为: 在系统运行时修复一些生产中与数据相关的问题(这对我来说是第一个) - DB和程序之间清晰的契约定义(清晰的关注点分离) -更好的可移植性到不同的DB供应商(如果写得好，代码更改通常只在SP端)。 -更好地进行性能调优

缺点:WHERE子句在使用条件上有很大的变化，需要高性能。

存储过程更易于维护，因为:

你不需要重新编译你的c#应用每当你想改变一些SQL 您最终会重用SQL代码。

当您试图构建可维护的应用程序时，代码重复是最糟糕的事情!

当您发现需要在多个地方纠正的逻辑错误时会发生什么?您更容易忘记更改复制和粘贴代码的最后一个位置。

在我看来，性能和安全性的提高是一个额外的加分项。您仍然可以编写不安全/低效的SQL存储过程。

更容易移植到另一个DB -没有pros到移植

在另一个DB中创建所有存储过程并不难。事实上，它比导出表更容易，因为不需要担心主键/外键。

在某些情况下，在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch)，它必须非常灵活，因此具有许多参数，非常复杂，那么您可能可以在运行时在代码中生成一个更简单的sql语句。

有人可能会说，这只是将一些处理从SQL转移到web服务器，但总的来说，这是一件好事。

这种技术的另一个优点是，如果你在SQL分析器中查找，你可以看到你生成的查询，调试它比看到一个存储的带有20个参数的proc调用要容易得多。

我更喜欢把它们保存在代码中(使用ORM，而不是内联或特别)，这样它们就可以被源代码控制覆盖，而不必保存.sql文件。

此外，存储过程本身并不更安全。使用sproc可以像使用内联一样轻松地编写糟糕的查询。参数化内联查询与sproc一样安全。