命令和MVVM原则 - RelayCommands

nrd*_*dev 5 command mvvm relaycommand

我是C#,WPF和MVVM模式的新手.对于这篇很长的帖子感到抱歉,我试图设置我所有的理解点(或不理解).

在研究了很多关于WPF和MVVM模式提供的命令机制的文本后,我有一些问题让我直截了当地思考如何使用这些东西.

我知道为WPF提供的命令允许为可视树的组件中保存的命令逻辑定义多个"调用点".当调用一个命令时,调用将通过可视树(从命令目标或聚焦元素开始)起泡,直到它碰到一个持有CommandBinding的元素,该CommandBinding定义了命令逻辑的位置.

看起来很不错的是,您可以在不指定逻辑和调用点的情况下定义公共命令.

我也理解,遵循MVVM模式,View的ViewModel应该处理逻辑,而命令的基本WPF实现只允许可视元素处理它,因为调用通过可视树冒泡.

然后我发现在这种情况下可以使用自定义实现,例如Josh Smith的RelayCommand,因为您将视图元素(例如按钮)调用的命令绑定到底层ViewModel中的RelayCommand对象.

但是,我不再看到它是一个命令(由WPF命令模式的定义),因为我们直接指定了ViewModel中引用的实现.使用这种方法,我们失去了能够从任何地方调用命令而不知道逻辑实现位置的所有好处.在这种情况下,为什么不直接使用Click事件处理程序(例如)?

有人可以解释一下我错在哪里吗?(感谢那些阅读帖子的人!)

问候.NR

Ree*_*sey 5

但是,由于我们直接指定了在 ViewModel 中引用的实现,因此我看不到它是如何成为命令的(根据 WPF 命令模式的定义)。

这仍然是一个命令,并实现了ICommand,但它不再利用 WPF 中内置的路由策略。它是一个命令,但不再是RoutedCommand - 所以从某种意义上说,你是对的 - 它没有遵循 WPF 路由命令基础结构的原始概念,但它仍然是一个命令。

使用这种方法,我们失去了能够从任何地方调用命令而不知道逻辑在哪里实现的所有好处。在这种情况下,为什么不直接使用 Click 事件处理程序(例如)?

您仍然保留了将逻辑与视图分离的好处。View 不需要知道这是如何实现的,ViewModel 可以在不知道 View 将如何触发它的情况下执行命令。命令仍然可以来自手势、按钮等 - 并且可以更改(完全在 XAML 中),而根本不更改逻辑和代码。

切换回事件处理程序会破坏这一点 - 如果您使用事件处理程序,更改视图的实现需要更新事件处理程序(代码隐藏)。

  • @Killercam 通常,您要调用的每个“方法”都封装在单个`ICommand` 中-不过,您可以拥有一个仅组合多个方法的`ICommand`(就像具有调用>1 个方法的方法一样)。 (2认同)