假设我有一个包含 、 和 等对象Customer的Employee应用Products程序CountyOfResidence。这些对象映射到数据库中的表。
在应用程序中，我们希望能够通过带有先前编写的存储过程的 GUI 搜索数据库。
这是命令模式有用的地方吗？
假设我们想了解客户和员工的平均年龄。在存储过程中使用一点动态 SQL，我可以设想类似的情况
FilterByAge(tableNameForDynamicSQL,typeWereFilteringAgainst)。或类似的东西FindPercentileRank(subject,tableName,type)。
使用 GUI 作为调用者并将存储过程作为命令的范例对我来说似乎足够直观。从那些有实践经验的人看来，这是您在这种情况下会使用的模式吗？
您所描述的听起来像Query Object Pattern，它非常类似于命令模式，但它特定于查询数据或对象。
您建议允许的定制级别具有明确的潜在安全性和性能影响。例如，如果可以将任意表名发送到存储过程，并且它构建的查询针对未针对 SQL 进行良好调整的表运行，那么您将面临暴露拒绝服务向量的风险。
我曾经有过类似的要求，我发现尽管需要更改搜索参数，但任何查询分类（您所说的“存储过程”）的返回列总是相同的。我使用此信息为每组返回值创建单一类型的查询对象。这些允许非常灵活的查询，完全清理所有输入。它工作得很好。
顺便说一句，在构建查询对象类型时，您不仅限于存储过程。您可以在代码中创建参数化 SQL，甚至可以构建可以运行的 LINQ 表达式树。
在存储过程中使用一点动态 SQL
所以你的 UI 将只是一个“存储过程参数编辑表单”，所有逻辑都在 SP 中？我去过那里，并且不会很快再这样做。
我宁愿让我的 UI 链接到一些业务逻辑（在数据库之外，但在与数据库对话的 DLL 或 web 服务中），这可以从某些输入参数构成适当的数据库调用。
这本身可以再次通过使用 ORM 轻松完成。
通常，命令模式不会返回任何结果。通常，它向系统发送命令并允许类封装命令的意图。
因此，它不完全符合您的要求。您的问题更多是关于封装查询。但是，我认为您可以以相同的方式封装查询。
您可能想查看规范模式而不是命令。Linq 本身是一种查询规范（使用表达式）。因此，如果您能够使用诸如 Linq to SQL 或实体框架之类的东西，那么其中大部分都是为您提供的。
如果你使用命令设计模式，应该有调用者、命令和接收者，存储过程应该链接到接收者而不是命令。
该命令可以在构造函数中使用一对接收器（调用存储过程），然后接收器在命令执行时执行实际任务。