我正在开发一个 WPF 应用程序，我非常了解命令模式，但我发现 MVVM 的命令模式有几种不同的实现。 Josh Smith 在他的 WPF 示例应用程序中的实现、Prism 的 DelegateCommand 和 CommandBindings 实现。
我的问题是，在 MVVM 中使用命令的公认最佳实践是什么？我的应用程序使用 Prism，因此我们可以使用 DelegateCommand。
我团队的开发人员正在争论哪种方法是“最好的”。有些人不喜欢为每个命令生成的大量 .cs 文件，其他人则更喜欢通过CommandBindings 连接所有内容。我不知所措。有人能解释一下吗？
【问题讨论】：
标签： wpf mvvm command command-pattern
嗯 - 我认为没有解决方案。
CommandBindings 是不容易测试的，并且在 ViewModel 中引入了对 WPF 类的依赖，这不是很好。 所以我不会使用它们。
DelegateCommand 和 CommandSinkCommand（Josh Smith 的解决方案）都是 IMO 的好方法。它们并没有真正的不同，也没有一个优于另一个。 不过，我注意到，当命令路由变得更复杂时（尤其是涉及 DataTemplates 时），CommandSink 版本并不总是有效。
您甚至可以将它们结合起来：使用 DelegateCommand 并另外使用 JoshSmith 版本 - 这样您就可以结合两者的优点。 您唯一需要的是一些辅助类 - 实现起来并不难。
更重要的是应用程序的一致性：如果您决定要使用什么，则应该在整个应用程序中遵循这种方式。
【讨论】：
需要考虑的两点：
不同 MVVM 框架提供的命令，例如 CommandSinkCommand 或 SimpleCommand（来自 Cinch）等，与普通 ICommand 一样工作。特别是，只要 WPF 认为发生了可能导致 UI 更改的事情，就会评估 CanExecute 处理程序。您也可以通过CommandManager.InvalidateRequerySuggested() 手动强制执行此操作。
与此相反，Prism 的 DelegateCommands 不会调用 CanExecute 处理程序，除非您在命令上手动调用 RaiseCanExecuteChanged()。如果您希望更改它以便在正常请求命令时也会触发它，请参阅http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338的代码
编辑：
第二点：MVVM框架的命令通常接受一个对象作为命令参数。相比之下，Prism 的 DelegateCommands 类型更强（当然，如果您愿意，也可以拥有 DelegateCommands）。
【讨论】：