将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。

到目前为止,我有:

in Code的优点:

更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植

存储Procs的优点:

性能 安全


当前回答

没有人提到单元测试!

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

其他回答

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

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

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

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

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

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

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

我不是存储过程的狂热爱好者,但我在一种情况下使用它们:

当查询相当大时,最好将其作为存储过程存储在数据库中,而不是从代码中发送。这样,就不会从应用服务器向数据库发送大量字符串字符,而只发送“EXEC SPNAME”命令。

当数据库服务器和web服务器不在同一个网络上(例如,internet通信)时,这是多余的。即使事实并非如此,太大的压力也意味着大量的带宽浪费。

但是,伙计,管理起来太糟糕了。我尽量避开他们。

坚定地站在“存储过程不利于CRUD/业务逻辑使用”的阵营。我了解在报告、数据导入等方面的需求

写在这里…

目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者,尽管有一些很好的论据支持Linq to Sql。

在代码中嵌入查询将您与数据模型紧密地结合在一起。存储过程是一种很好的契约式编程形式,这意味着DBA可以自由地更改过程中的数据模型和代码,只要存储过程的输入和输出所表示的契约得到维护。

当查询隐藏在代码中,而不是在一个易于管理的中心位置时,调优生产数据库可能会非常困难。

这里是另一个当前的讨论