.net - ICommand 如何以及在何处融入整个 WPF MVVM 模式？

Question

我正在尝试学习如何使用 WPF 命令，以及它们如何适应 MVVM 模式。据我所知，某些控件(例如按钮或菜单)具有 Command 属性，当设置为 ICommand 类的实例时，该属性会将按钮连接到该命令。设置完成后，按钮将通过命令的 CanExecuteChanged 事件禁用和启用，并且单击控件将调用命令的 Execute 方法。

但是，每个 ICommand 的实例应该位于哪里？我在教程中看到了各种不同的选项，但不确定哪个是正确的。在一些示例中，创建静态“ApplicationCommands”类并且将每个命令的实例分配给该类的静态属性。在其他示例中，我看到命令设置为 ViewModel 的属性，以及在其他示例中设置为 View/Window 本身的属性。命令实例的首选驻留位置是什么？

此外，命令如何与 View 、 View 模型或模型相关？命令应该了解和/或操作哪些组件？执行命令时会发生什么？它是否应该调用模型的某些方法，然后将更改传达回 View 模型/ View ？或者命令应该通过 View 模型的方法与模型通信？

Answer 1

In some examples a static "ApplicationCommands" class is created and an instance of each command is assigned to a static property of that class

您可以为您希望能够从任何地方访问的命令执行此操作。例如，如果您希望 F1 的键绑定(bind)始终显示帮助屏幕，那么您可以在一个全局可访问的位置实现此命令，然后从各个屏幕绑定(bind)到它。

seen commands set as properties of the ViewModel, and in others of the View/Window itself.

如果命令正在对数据执行某些操作，那么 ViewModel 是执行此操作的好地方。如果该命令不需要对数据执行任何操作，则将其放在 View 后面的代码中(因为它与 ViewModel 无关，并且您不需要用它污染 ViewModel)。一个有趣的情况是，当您执行诸如响应击键而弹出对话框之类的操作时，并且需要将当前选定的网格项传递到对话框 - 命令应该放在哪里？在这种情况下，我会将其放在 View 后面的代码中，因为没有令人信服的理由将其放在 ViewModel 中 - 如果需要， View 可以从 ViewModel 中检索所选项目。

我多次看到不必要地将命令放入 ViewModel 中，只是因为人们认为这是唯一的方法。我使用的经验法则是:如果它正在执行 UI 相关工作，那么它属于 View 后面的代码。如果它正在执行与数据相关的工作，那么它可以进入 ViewModel。如果它是混合的，那么请考虑分解 View 和 ViewModel 之间的功能。

Which of these components should the command be aware of and or manipulate?

仅需要了解的内容。从 ViewModel 访问模型等组件应该通过正确定义的属性或返回接口(interface)的函数来完成，这是为了避免紧密耦合。

Should it call some method of the Model which then communicates changes back to the View Model/View?

从 ViewModel 访问 Model 的命令没有问题。该命令可以更新 ViewModel 或 Model 上的属性，并且通过数据绑定(bind)和属性通知的魔力，这些更新可以反射(reflect)回 UI 中。