问题标签 [command-pattern]

允许访问者修改接收者的状态通常是可以接受的，还是应该改为命令模式？

好吧，这有点傻。我正在尝试使用 MVC 和命令模式。这些问题主要涉及在哪里放置代码。

在 MVC 模式中，命令在哪里实例化？它们是由控制器创建的，还是完全包含在模型中，或者两者都没有。

顺便说一句，如果不需要撤消/重做，是否应该使用命令模式。

问候

根据此视频[ @ 7:50]，Google 建议在其请求处理 API 之上使用命令模式。还有一个看起来很有帮助的项目gwt-dispatch实现了该模式。

根据 gwt-dispatch文档，我需要为每个命令创建四个类：

• 一个动作（例如命令）
• 结果（例如响应）
• 动作处理程序
• 一个模块

假设我的服务 API 在 8 个 BSO 中有 100 个方法，有人可以向我解释为什么我要创建近 400 个新类吗？这种模式有什么令人敬畏的？

我想要实现的是在持久存储（数据库）上有一个“可撤销”更改的持久列表。

该体系结构为域对象使用存储库，为事务使用工作单元，对于我想到的使用命令模式的最后部分（撤消）。但是，对我来说，如何使执行的命令持久化似乎没有很好的解决方案。

基本上，存储库添加/更新/删除有 3 个写操作，并且使用命令模式，我需要在执行命令之前存储状态。例如：我必须在删除之前存储域对象（实体），以便在命令上调用撤消后可以恢复它。这里最大的问题是如何以简洁的方式存储之前的状态！

也许你们中的一些人遇到了同样的问题，在我看来这并不少见。

谢谢，克里斯

我在 wpf 上下文中有两个菜单项，我将它们与命令绑定，当两个项目都不可用时如何隐藏上下文菜单，我的意思是当两个命令都无法执行时？

假设我正在实现一个 Winforms UI，其中所有命令都遵循以下模式：

触发此类命令的按钮或菜单项应具有以下设置：

• 属性Enabled绑定到命令的CanExecute
• 事件Click链接到命令的Execute（由于方法签名不同，通过中间事件处理程序）

麻烦的CanExecute是，INotifyPropertyChanged在这里实现它不会起作用，因为这个属性不能直接修改，而是取决于程序中的其他因素，不需要与命令相关。并且不必PropertyChanged在程序的完全不相关的部分中触发命令事件。

您如何让数据绑定管理器知道何时CanExecute更改？

这是我的问题的一个（纯属虚构）示例：

理想情况下，我希望 UI 不断检查CanExecute（好像它是一个易失性字段），但 AFAIK 这不是 Winforms 数据绑定的工作方式。有没有人有这个问题的解决方案？

_{注意：我知道 WPF，顺便说一句。我的问题的背景是，我将在 WPF 的大方向上逐步改进现有的 Winforms 应用程序。但实际上使用 WPF 并因此摆脱我所问的问题现在是不可行的。}

当您想要实现具有撤消/重做功能的模型时，经常使用众所周知的命令模式。我正在寻找一个实现撤消/重做的简单 Delphi 表单的参考实现（示例）。

据我所见，带有三个编辑框、六个备忘录框、几个组合框和其他简单编辑控件的简单 delphi 数据输入表单通常不支持撤消/重做。

有没有人见过设计良好的 delphi 方法，它使用单独的 Delphi 视图（表单）和模型对象（数据对象与表单的所有编辑同步更新，对复杂的模型-视图-控制器设计提供多级撤消/重做支持，并且验证和控制逻辑不是嵌入到表单中，也不是嵌入到模型中，而是分离出来的。

在我看来，如果您不必使用 MVC，并且您需要简单地制作一个没有模型或控制器对象的 Delphi 演示应用程序原型，那么纯简单 Delphi 的撤消/重做“one-form-is-my” -app" 设计起来会更简单，但它会变得更复杂，因为您需要记录和重放对象并将它们同步到 Delphi 表单操作，如 TEdit.OnChange。

我见过很多命令模式的例子

但它们都倾向于在桌面应用程序的上下文中。

即“命令将调用操作的对象与知道如何执行它的对象分离”

在纯 HTML（但 Zend Framework MVC 驱动）网站的上下文中，我正在考虑用户“单击链接”，该链接应该刷新当前页面并调用某个命令。无论用户在网站的哪个页面上。

例如，在博客应用程序中：

IE

为了能够在两者上都显示 HTML 表单按钮，例如“删除博客文章”：

• “列表页面”（列出博客文章）

• “编辑页面”（编辑博客文章）

• “列表页面”上的表单操作指向“列表页面”

• “编辑页面”上的表单操作指向“编辑页面”

我怀疑 ZF MVC 的控制器部分是一种命令模式。但是，这会将 URL 路由到特定的控制器。我正在尝试同时将命令操作路由到特定的命令接收器。

命令模式是否适用于此，还是仅在富图形用户界面的上下文中真正有用 - 例如桌面应用程序或启用 AJAX 的站点？

两种设计模式都封装了算法并将实现细节与其调用类分离。我能辨别的唯一区别是策略模式接受参数来执行，而命令模式没有。

在我看来，命令模式需要在创建时提供所有执行信息，并且它能够延迟其调用（可能作为脚本的一部分）。

哪些决定指导是否使用一种模式或另一种模式？

是否可以使用 Queue of Action 委托来实现 GOF 命令模式？

一段时间以来，我一直试图绕开它，但我很困惑，因为我想添加到队列中的每个可能的操作都可能有不同数量的参数。

有什么建议么？我是否通过专注于命令模式来找出错误的树？

更新：

非常感谢 jgauffin，它很有效......我的实现现在看起来像