WPF: MVVM: Command和CallMethodAction有什么区别？

Question

我正在通过一个新的（小）项目学习MVVM模式，并且我有一个关于在控制器上调用操作的问题：

我看过很多教程，他们告诉我们使用Command，意味着声明一个RelayCommand，初始化它并创建由RelayCommand调用的操作。

另一方面，我的同事告诉我可以使用触发器中的CallMethodAction：

<i:Interaction.Triggers> 
  <i:EventTrigger> 
    <ei:CallMethodAction MethodName="Init" TargetObject="{Binding}" /> 
  </i:EventTrigger> 
</i:Interaction.Triggers> 

对我来说，他的方法的优点在于我不必为命令编写一些初始化方法（可能永远不会被使用）。

那么我错过了什么？为什么每个人都使用命令？

- J4N

Answer 1

命令是开箱即用的解决方案，只能附加到实现ICommand接口的元素上。另一方面，事件触发器可以附加到任何事件上，这使它们更加灵活。我遵循通常策略，将命令用于涉及用户交互的场景（按钮、菜单），并且需要使用CanExecute模式。我的命令严格与视觉界面相关联（提供标题、图像源等）。在其他情况下，当我想要摆脱代码后台时，我使用CallMethodAction。

- amnezjak

Answer 2

命令提供了在ViewModel代码中禁用功能。这可以用于自动禁用绑定到命令的按钮。这就是使命令更好的原因。此外，基于您的逻辑，您可以动态地从同一插槽中拔出另一个命令，并重新路由来自View的流量，而在CallMethodAction中，您必须在调用的方法中编写重路由逻辑，这将很丑陋。

正如您所看到的，这取决于您尝试完成的任务以及您的逻辑有多复杂 :)

- Paweł Motyl

---

好的，你是在谈论“canExecute”对吧？我没有考虑过这个。但是，在MVVM上下文中，这两种解决方案都没有错吗？ - J4N

我不知道是否应该说CallMethodAction是“错误”的，但是……从可读性和可维护性的角度来看：当您在VM上有一个Command属性时，它向所有人显示这是View流程进入的点。如果使用CallMethodAction，则会降低可维护性。在我看来（请注意，这只是个人意见），应该少量使用CallMethodAction，并且RelayCommand应该是与VM交互的默认方式。问题只有一个：Blend SDK中没有ExecuteCommand操作，但可以轻松编写。 - Paweł Motyl

你的回答对我非常有用，但是我不理解以下这句话的意思：“在相同的插槽中使用Command将重新路由来自View的流量，而在CallMethodAction中，您需要编写重新路由逻辑”...你能给我举个例子吗？@Paweł Motyl - Madhu