对存储过程使用命令模式

本文关键字：命令 模式 存储过程 | 更新日期: 2023-09-27 18:32:58

假设我有一个应用程序，其中包含Customer、Employee、Products和CountyOfResidence等对象。这些对象映射到数据库中的表。

在应用程序中，我们希望能够通过具有先前编写的存储过程的GUI搜索数据库。

这是命令模式有用的地方吗？

假设我们想了解客户和员工的平均年龄。 在存储过程中使用一些动态 SQL，我可以设想类似 FilterByAge(tableNameForDynamicSQL,typeWereFilteringAgainst) .或者像FindPercentileRank(subject,tableName,type).

使用 GUI 作为调用程序并将存储过程作为命令的范例对我来说似乎足够直观。 从那些有实践经验的人那里，这是你在这种情况下会使用的模式吗？

对存储过程使用命令模式

您描述的内容听起来像查询对象模式，它非常类似于命令模式，但它特定于查询数据或对象。

您建议允许的自定义级别具有明确的潜在安全性和性能影响。例如，如果可以将任意表名发送到存储过程，并且它生成的查询针对未针对 SQL 优化的表运行，则存在公开拒绝服务向量的风险。

我

曾经有过类似的要求，我发现，尽管搜索参数需要更改，但任何查询分类(您称之为"存储过程"(的返回列始终相同。我使用此信息为每组返回值创建单一类型的查询对象。这些允许极其灵活的查询，完全清理所有输入。效果很好。

顺便说一句，在生成查询对象类型时，您不限于存储过程。可以在代码中创建参数化 SQL，甚至可以生成可以运行的 LINQ 表达式树。

通常，命令模式不会返回任何结果。 通常，它向系统发送命令并允许类封装命令的意图。

因此，它不完全符合您的要求。 您的问题更多是关于封装查询。 但是，我认为您可以以相同的方式封装查询。

您可能希望查看规范模式而不是命令。 Linq 本身是一种查询规范(使用表达式(。 因此，如果您能够使用 Linq to SQL 或实体框架之类的内容，则可以为您提供其中的大部分内容。

在存储过程中使用一些动态 SQL

所以你的UI将只是一个"存储过程参数编辑表单"，所有逻辑都将在SP中？我去过那里，不会很快再这样做了。

我宁愿让我的 UI 链接到一些业务逻辑(在数据库之外，但在与数据库通信的 DLL 或 Web 服务中(，这些逻辑可以从某些输入参数组成适当的数据库调用。

这本身也可以通过使用ORM轻松完成。

如果您使用的是命令设计模式，则应有调用程序、命令和接收器，存储过程应链接到接收器而不是命令。

该命令可以在构造函数中获取几个接收器(调用存储过程(，然后接收器在执行命令时执行实际任务。

相关文章：