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

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

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

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

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

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

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

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

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

@Terrapin - scprocs同样容易受到注射攻击。正如我所说:

总是参数化所有的查询-永远不要内联用户输入的东西，你会没事的。

这适用于sprocs和动态Sql。

我不确定不重新编译你的应用程序是一个优势。我的意思是，在重新上线之前，您已经针对该代码(应用程序和DB)运行了单元测试。

@Guy -是的，你是对的，sproc确实让你控制应用程序用户，这样他们就只能执行sproc，而不是底层的操作。

我的问题是:如果所有人都通过你的应用程序访问它，使用连接和用户只有有限的更新/插入权限等，这个额外的级别是否增加了安全性或额外的管理?

我的观点是后者。如果他们已经破坏了您的应用程序，可以重新编写它，那么他们还有很多其他的攻击可以使用。

如果动态内联代码，Sql注入仍然可以针对这些spprocs执行，所以黄金法则仍然适用，所有用户输入必须始终参数化。

我们在Oracle数据库中使用存储过程。我们也使用Subversion。所有存储过程都被创建为.pkb & .pks文件并保存在Subversion中。我以前做过内嵌SQL，这很痛苦!我更喜欢我们在这里的方式。创建和测试新的存储过程比在代码中执行要容易得多。

特蕾莎

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

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

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

我更喜欢使用O/R映射器，如LLBLGen Pro。

它为您提供了相对轻松的数据库可移植性，允许您使用强类型对象用与应用程序相同的语言编写数据库访问代码，并且在我看来，允许您更灵活地处理所拉回的数据。

实际上，能够使用强类型对象是使用O/R Mapper的充分理由。