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

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

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

我喜欢存储过程，不知道有多少次我能够使用存储过程对应用程序进行更改，而不会对应用程序产生任何停机时间。

作为Transact SQL的忠实粉丝，调优大型查询已被证明对我非常有用。我已经6年没有写过任何内联SQL了!

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

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

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

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

在我工作的地方，sproc的最大优势是我们有更少的代码移植到VB。NET(来自VB6)。而且它的代码更少，因为我们对所有的查询都使用了spprocs。

当我们需要更新查询而不是更新VB代码，重新编译并在所有计算机上重新安装它时，它也有很大的帮助。

没有人提到单元测试!

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