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

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

我站在代码这一边。我们构建了所有应用程序(包括web和客户端)使用的数据访问层，所以从这个角度来看这是DRY。它简化了数据库部署，因为我们只需要确保表模式是正确的。它简化了代码维护，因为我们不需要查看源代码和数据库。

在与数据模型的紧密耦合方面，我没有遇到太多问题，因为我看不出哪里有可能真正打破这种耦合。应用程序及其数据在本质上是耦合的。

我非常支持代码而不是SPROC。第一个原因是保持代码紧密耦合，第二个原因是源代码控制的便利性，而不需要大量自定义实用程序。

在我们的DAL中，如果我们有非常复杂的SQL语句，我们通常将它们作为资源文件，并在需要时更新它们(这也可以是一个单独的程序集，并在每个db中交换，等等……)

这使得我们的代码和sql调用存储在同一个版本控制中，而不会“忘记”运行一些外部应用程序进行更新。

没有人提到单元测试!

如果你有一个saveOrder方法，你可以在里面调用几个方法，并为每个方法创建一个单元测试，但如果你只调用一个存储过程，就没有办法做到这一点。

存储过程的性能优势通常可以忽略不计。

存储过程的更多优点:

防止反向工程(当然，如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便

@Keith

安全?为什么scprocs会更安全?

存储过程提供了抵御SQL注入攻击的内在保护。

然而，您并没有完全受到保护，因为您仍然可以编写容易受到此类攻击的存储过程(即存储过程中的动态SQL)。