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

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

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

@Keith

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

正如Komradekatz所建议的，您可以禁止访问表(对于连接到DB的用户名/密码组合)，而只允许SP访问。这样，如果有人获得了数据库的用户名和密码，他们可以执行SP，但不能访问表或数据库的任何其他部分。

(当然，执行scproc可以给他们所有他们需要的数据，但这将取决于可用的scproc。给他们访问表的权限，他们就能访问所有东西。)

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

存储过程的更多优点:

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

我通常写OO代码。我猜你们大多数人可能也有同感。在这种上下文中，所有业务逻辑(包括SQL查询)都属于类定义，这在我看来是显而易见的。分割逻辑(部分驻留在对象模型中，部分驻留在数据库中)并不比将业务逻辑放到用户界面中更好。

关于存储过程的安全性优势，在前面的回答中已经说了很多。它们分为两大类:

1)限制直接访问数据。这在某些情况下确实很重要，当你遇到这样的情况时，存储过程几乎是你唯一的选择。然而，根据我的经验，这样的情况是例外而不是规则。

2) SQL injection/parametrized queries. This objection is a red herring. Inline SQL - even dynamically-generated inline SQL - can be just as fully parametrized as any stored proc and it can be done just as easily in any modern language worth its salt. There is no advantage either way here. ("Lazy developers might not bother with using parameters" is not a valid objection. If you have developers on your team who prefer to just concatenate user data into their SQL instead of using parameters, you first try to educate them, then you fire them if that doesn't work, just like you would with developers who have any other bad, demonstrably detrimental habit.)

我想再投一票赞成使用存储过程(尽管在维护和版本控制时它们会带来麻烦)作为一种限制对底层表的直接访问以获得更好的安全性的方法。

没有人提到单元测试!

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