首先有一个partial question 与此相关，但这并不是我要问的，所以请耐心等待。
我的问题是，在查看了 SubSonic 所做的事情以及 Rob Connery 的精彩视频之后，我需要问：我们应该使用这样的工具并进行内联查询还是 使用对存储过程的调用？
我不想最小化 Rob 的任何工作（我认为这很了不起），但我只是想听听您对此的看法，因为我需要开始一个新项目，而且我处于中间位置；我应该使用 SubSonic（或其他类似工具，如 NHibernate）还是继续我的方法，即使它很简单，也总是调用存储过程
Select this, that from myTable where myStuff = StackOverflow;
【问题讨论】：
标签： sql stored-procedures subsonic
它不需要是一个或另一个。如果是简单查询，请使用 SubSonic 查询工具。如果更复杂，请使用存储过程并加载集合或根据结果创建数据集。
请看这里：What are the pros and cons to keeping SQL in Stored Procs versus Code 和这里SubSonic and Stored Procedures
【讨论】：
当您有多个依赖于同一个数据库的应用程序时，存储过程是黄金。它让您定义和维护查询逻辑一次，而不是几个地方。
另一方面，存储过程本身很容易在数据库中变得一团糟，因为大多数系统都没有很好的方法来对它们进行逻辑组织。而且它们可能更难以版本化和跟踪更改。
【讨论】：
我个人不会遵循严格的规则。当然，在开发阶段，您希望能够快速更改查询，因此我会将它们内联。
稍后，我将转向存储过程，因为它们具有以下两个优点。我敢肯定还有更多，但这两个赢得了我的支持。
1/ 存储过程将数据和用于操作/提取该数据的代码组合在一个点上。这使您的 DBA 的生活变得更加轻松（假设您的应用程序足够大以保证 DBA），因为它们可以根据已知因素进行优化。
DBA 的一大难题是即席查询（尤其是那些不知道全表扫描是什么的小丑）。 DBA 更喜欢有良好的一致查询，他们可以调整数据库。
2/ 存储过程可以包含最好留在数据库中的逻辑。我在 DB2/z 中看到存储过程有很多行，但所有客户端必须编写的代码只有一行，例如“给我那个列表”。
因为“那个列表”的逻辑存储在数据库中，DBA 可以随意修改它的存储和提取方式不会影响或更改客户端代码。这类似于使面向对象语言比以前更“干净”的封装。
【讨论】：
我已经完成了内联查询和存储过程的混合。我更喜欢存储过程/视图方法，因为它为您在需要时进行更改提供了一个好地方。当您有内联查询时，您总是必须更改代码以更改内联查询，然后重新滚动应用程序。您还可能在多个位置使用内联查询，因此与使用一个存储过程相比，您必须更改更多代码。
再一次，如果您必须向存储过程添加参数，您仍然会更改很多代码。
另一个注意事项是存储过程背后的数据更改频率，在我工作的地方，我们有可能分解为规范化表的第三方表，或者表变得过时。在这种情况下，存储过程/视图可以最大限度地减少您对该更改的影响。
我还编写了一个没有存储过程的完整应用程序。它有 3 个类和 10 页，根本不值得。我认为它的过度杀伤力或可以证明是有道理的，但这也归结为您的个人意见和偏好。
【讨论】：
您打算只从那个应用程序访问您的数据库吗？
如果不是，那么您最好使用存储过程，这样您就可以获得与数据库一致的接口。
如果您需要进行更改，分发您的应用程序是否有任何重大成本？
如果是这样，那么您最好使用可以在服务器上更改并且不需要分发这些更改的存储过程。
您是否担心数据库的安全性？
如果是这样，那么您可能希望使用存储过程，这样您就不必向用户授予对表的直接访问权限。
如果您正在为一个不会在您的应用程序之外使用或访问的系统编写一个没有广泛受众的小型应用程序，那么内联 SQL 可能没问题。
【讨论】：
使用 Subsonic，您将使用内联、视图和存储过程。亚音速使数据访问更容易，但您无法在亚音速查询中做任何事情。虽然是最新版本，但 2.1 越来越好。
对于基本的 CRUD 操作，内联 SQL 将是直截了当的。对于更复杂的数据需求，需要创建一个视图，然后您将对视图执行 Subsonic 查询。
存储过程适用于更难的数据计算和数据检索。基于集合的检索通常总是比程序处理更快。
当前的 Subsonic 应用程序使用所有三个选项并取得了很好的效果。
【讨论】：
除非存储过程涉及实际逻辑（变量、游标等），否则我更喜欢内联 sql。我最近一直在使用 LINQ to SQL，并获取生成的类并添加具有一些预定义的常见 linq 查询的部分类。我觉得这有助于加快开发速度。
编辑：我知道我会为此被降级。如果你曾经谈论过外键或存储过程，你就会被贬低。我猜 DBA 需要工作保障......
【讨论】：
存储过程的优点（在我看来）
【讨论】：
存储过程将数据和用于操作/提取该数据的代码组合在一个点上。这使您的 DBA 的生活变得更加轻松（假设您的应用程序足够大以保证 DBA），因为它们可以根据已知因素进行优化。
存储过程可以包含最好留在数据库中的逻辑。我在 DB2/z 中看到存储过程有几十行，但所有客户端必须编写的代码只有一行，比如“给我那个列表”。
我发现使用存储过程的最大优点是，当我们想要更改逻辑时，在内联查询的情况下，我们需要去每个地方并更改它并重新滚动每个应用程序，但在仅在一处需要更改存储过程的情况。
所以当你有清晰的逻辑时使用内联查询；否则更喜欢存储过程。
【讨论】：
we need to go to everyplace 那么你做错了！ “不要重复自己”应该是每个开发人员的主题，此外，问题的标签说它是一个 ORM，需要处理的代码更少，并且使用存储库，您的代码将只保留在一个地方，只需一次调用。