有没有比在后面的代码中处理 CommandBindings 更好的方法？答案

【问题标题】：Is there a better way than handling CommandBindings in code behind?有没有比在后面的代码中处理 CommandBindings 更好的方法？
【发布时间】：2012-03-12 02:39:02
【问题描述】：

我有一个使用 MVVM 的应用程序。我正在尝试拦截 MCE 遥控器上的按键以进行播放、暂停、停止等...... 目前，我正在将命令绑定与代码中的方法一起使用，以便对媒体元素执行相关操作

<Window.CommandBindings>
    <CommandBinding Command="MediaCommands.Play" Executed="PlayMediaElement"/>
    <CommandBinding Command="MediaCommands.Stop" Executed="StopMediaElement"/>
</Window.CommandBindings>

在尝试包含远程控制功能之前，我有大约 10 个视图模型/视图，后面没有任何代码。我想知道是否有更好的方法来做到这一点，所以我保留了 MVVM 模式，或者以这种方式实现是完全可以接受/更可取的。

编辑 - 我已将视图内的 UserControl 中的命令绑定移动到我的 MainWindow.xaml 中，并将方法放入 MainWindow.xaml.cs。 MainWindow 没有视图/视图模型关系，只是一个带有链接到它的视图模型的内容控件。在我的方法背后的代码中，我使用调解器将消息（播放、暂停、停止等）发送到我的 mediaplayerviewmodel，然后与它各自的视图交互。这是个好主意还是有更好的方法？

【问题讨论】：

How to locate the source of a binding error?

标签： wpf mvvm

【解决方案1】：

前往 Codeplex.com 并寻找 Caliburn（或更好的 Caliburn Micro）。它扩展了 WPF 以实际允许调用具有从其他对象中提取的任意参数的方法，并且该方法位于视图模型/控制器中，而无需在代码中使用“钩子方法”来转发调用。

扩展可以做一些奇妙的事情，比如拉取文本框的值并将其作为参数传递给方法，然后对返回值做出反应——就像视图一样。

您在“库存” wpf 的限制下运行 - 它只能指向后面代码中的方法处理程序，而不考虑参数。存在替代方案，甚至来自微软。

【讨论】：

【解决方案2】：

我认为 Josh Smith 在他 2009 年的文章中造成了巨大的混乱，当时他指出他的代码隐藏 CS 文件大部分都是空的。 MVVM 并不是没有代码隐藏。它是关于关注点的分离。如果您应该遵循任何实际规则，那就是使 ViewModel 视图不可知（即没有从 ViewModel 到 View 的引用。考虑为您的 ViewModel 进行“视图”的第二个单元测试实现）。

这种“没有代码背后”的混乱导致了非常奇怪的结构，只是为了解决一个本来就不应该存在的问题。

在 MainWindow.xaml.cs 中包含代码是完全合理的解决方案，只要您没有逻辑，只需将调用转发到视图模型中的适当方法即可。如果那是我的代码，我会创建直接绑定到 ViewModel 中的命令的自定义命令（同一篇文章中的 DelegateCommand），但您的设计也是 100% 合法的。

【讨论】：

实际上不，这是库存 WPF 的限制。 Stock WPF 无法合理调用视图或控制器上定义的方法。
不确定为什么会被标记下来？我已经根据最后一段提出了解决方案。我创建了自定义路由命令，这些命令会冒泡到主窗口（没有视图），但确实可以操作视图模型。