我是C＃，WPF和MVVM模式的新手。对于这篇很长的帖子感到抱歉，我试图设置所有理解点（或不理解）。
在研究了很多关于WPF和MVVM模式提供的命令机制的文本后，我有一些问题让我直截了当地思考如何使用这些东西。
据我所知，为WPF提供的命令允许为可视树的组件中保存的命令逻辑定义多个“调用点”。当一个命令被调用时，调用将通过可视树（从命令目标或聚焦元素开始）起泡，直到它碰到一个持有CommandBinding的元素，该CommandBinding定义了命令逻辑的位置。
看起来很不错的是，您可以在不指定逻辑和调用点的情况下定义公共命令。
我也理解，遵循MVVM模式，View的ViewModel应该处理逻辑，而命令的基本WPF实现只允许可视元素处理它，因为调用通过可视树冒泡。
然后我发现在这种情况下可以使用自定义实现，例如Josh Smith的RelayCommand，因为您将视图元素（例如按钮）调用的命令绑定到基础ViewModel中的RelayCommand对象。
但是，我不再看到它是一个命令（通过WPF命令模式的定义），因为我们直接指定了ViewModel中引用的实现。使用这种方法，我们失去了能够从任何地方调用命令而不知道逻辑实现位置的所有好处。在这种情况下，为什么不直接使用Click事件处理程序（例如）？
有人能解释我哪里错了吗？ （感谢那些将帖子读到最后的人！）
的问候。 NR
答案 0 :(得分：4)
但是，我不再看到它是一个命令（通过WPF命令模式的定义），因为我们直接指定了ViewModel中引用的实现。
这仍然是一个命令，并实现ICommand，但它不再利用WPF内置的路由策略。这是一个命令，但不再是RoutedCommand - 所以从某种意义上说，你是对的 - 它不遵循WPF路由指挥基础设施的原始概念，但它仍然是一个命令。
使用这种方法，我们失去了能够从任何地方调用命令的所有好处，而无需知道逻辑的实现位置。在这种情况下，为什么不直接使用Click事件处理程序（例如）？
您仍然保持将逻辑与View分开的好处。 View不需要知道如何实现它，ViewModel可以在不知道View如何触发它的情况下实现命令。该命令仍然可以来自手势，按钮等 - 并且可以更改（完全在XAML中），而无需更改逻辑和代码。
切换回事件处理程序会破坏这一点 - 如果使用事件处理程序，更改View的实现需要更新事件处理程序（代码隐藏）。
答案 1 :(得分：0)
在进一步研究如何在MVVM项目中使用原始WPF命令行为后，我发现了这个链接：http://matthamilton.net/commandbindings-with-mvvm！
据我所知，它提供了一种“附加”视图的方法，由viewmodel处理的CommandBindings。这样，viewmodel就能够实现在命令调用遍历可视树时发现的命令绑定。
再见。