在存储过程中保持SQL相对于代码的利弊是什么？

Question

在存储过程中保持SQL相对于代码的利弊是什么？在C#源代码或存储过程中保留SQL的优点/缺点是什么？我一直在和一个朋友讨论我们正在进行的开源项目(C#ASP.NETForum)。目前，大多数数据库访问都是通过在C#中构建SQL内联并调用SQLServerDB来完成的。所以我试图确定，对于这个特定的项目，哪一个是最好的。到目前为止，我已经：守则的优点：维护起来更容易-不需要运行SQL脚本来更新查询更容易移植到另一个DB-没有pros到端口储存产品的优点：性能保安

Answer 1

在我看来，你不能在这个问题上投赞成票或反对票。这完全取决于应用程序的设计。

我完全反对在3层环境中使用SPS，因为前面有一个应用服务器。在这种环境中，您的应用程序服务器可以运行您的业务逻辑。如果您另外使用SPS，您将开始在整个系统中分发业务逻辑的实现，并且将变得非常不清楚谁对什么负责。最终，您将得到一个应用程序服务器，它将只执行以下操作：

(Pseudocode)Function createOrder(Order yourOrder) Begin
  Call SP_createOrder(yourOrder)End

最后，您可以在这个非常酷的4Server集群上运行您的中间层，每个集群都配备了16个CPU，它实际上什么也做不了！多浪费呀!

如果您有一个可以直接连接到DB或更多应用程序的胖GUI客户机，那么情况就不同了。在这种情况下，SPS可以充当某种伪中间层，将应用程序与数据模型解耦，并提供可控制的访问。