wpf - 为什么偏爱 RelayCommand 而不是 RoutedCommand？

Question

我正在尝试学习 MVVM 软件设计模式。我有 Matthew MacDonald 的书“Pro WPF in C# 2010”来更好地学习 WPF。在尝试开始学习 MVVM 时，我查看了 WindowsClient.net 网站，尤其是 Todd Miranda 的视频“我如何:使用 MVVM 模式构建数据驱动的 WPF 应用程序”。他在其中简要讨论了 RoutedCommand，但基于 ICommand 接口(interface)编写了自己的名为 RelayCommand 的类的实现。

这看起来很有希望，但我遇到了一个问题，因为我正在开发的窗口(一个带有文本框的简单窗口，以及使用用户输入的参数进行搜索并在列表框中返回结果的按钮)是比托德所做的更复杂。基本上，我找不到一种方法来获取用户在我编写的 RelayCommand 类中输入的搜索参数，该类返回一个我称为 AllClients 的 ObservableCollection(显示在列表框中)。

MacDonald 的书讨论了 RoutedCommand，尤其是 RoutedUICommand，坦率地说，这看起来对我正在尝试做的事情很有希望。然而，为了更好地理解 MVVM 模式，我快速浏览了 Amazon 上有哪些书籍可以帮助学习 MVVM 模式，并找到了一些书籍，例如 Gary Hall 的“Pro WPF and Silverlight MVVM”。在那本书中，霍尔似乎强烈建议 RoutedCommand 路线不是要走的路。这是有问题的，因此最好使用 RelayCommand。

坦白说，我真的很困惑。首先，我完全不理解霍尔的论点。为什么使用 RoutedCommands(或者也可能是 RoutedUICommands)是一个糟糕的选择？为什么使用 RelayCommands 如此优越？

Answer 1

一般来说，我发现 RoutedCommand 经常过大。在 WPF ICommand vs RoutedCommand 中对其功能有很好的解释。 .

我认为 RelayCommand 的优越性来自于它的易用性和直接性。它仅使用 View 模型中的 Execute 和可选的 CanExecute 事件处理程序进行实例化。在我只想将一些功能连接到按钮、菜单项等的情况下，这一直很好。

如果您有任何需要传递命令的参数，我建议将它们放在您的 View 模型中，紧挨着命令实现所在的位置。例如，对于搜索命令，您可以将文本框绑定(bind)到包含搜索文本的 View 模型中的字符串属性。当您的命令的 Execute 事件处理程序被调用时，它将获取该属性的值并将其传递给您在模型中实现的搜索例程。因此，我认为不需要使用命令的 Parameters 属性。 View 模型方法更加灵活，并允许多个参数。