有没有比在代码后面处理 CommandBindings 更好的方法？
我有一个使用 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 没有视图/视图模型关系，只是一个链接有 ViewModel 的内容控件。 在我的代码隐藏方法中，我使用调解器将消息（播放、暂停、停止等...）发送到我的 mediaplayerviewmodel，该模型又与其各自的视图进行交互。这是一个好主意还是有更好的方法？
I have an application using MVVM. I'm trying to Intercept key presses on an MCE Remote control for Play, Pause, Stop etc....
Currently I'm using command bindings with a method in the code behind performing the related action on a media element as such
<Window.CommandBindings>
<CommandBinding Command="MediaCommands.Play" Executed="PlayMediaElement"/>
<CommandBinding Command="MediaCommands.Stop" Executed="StopMediaElement"/>
</Window.CommandBindings>
Before trying to include the remote control functionality I had approx 10 view-models/views with nothing in code behind.
I'm wondering if there is a better way to do this so I retain the MVVM pattern or is it perfectly acceptable/preferable to implement in this way.
EDIT - I've moved the Command Bindings from a UserControl inside a View into my MainWindow.xaml and placed the methods into MainWindow.xaml.cs. MainWindow doesn't have a view/viewmodel relationship, simply a content control with a ViewModel linked to it.
In my code behind methods I'm making use of a Mediator to send messages (Play,Pause,Stop etc...) to my mediaplayerviewmodel which in turn interacts with it's respective view. Is this a good idea or is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 Josh Smith 在他 2009 年的文章中造成了巨大的混乱，当时他指出他的代码隐藏 CS 文件大部分都是空的。 MVVM 并不是没有代码隐藏。这是关于关注点分离的。如果您应该遵循任何实际规则，那就是使 ViewModel 视图不可知（即，没有从 ViewModel 到视图的引用。考虑为您的 ViewModel 提供“视图”的第二个单元测试实现）。
这种“无代码隐藏”的混乱导致了非常奇怪的结构，只是为了解决一个本来就不应该存在的问题。
将代码放在 MainWindow.xaml.cs 中是完全合理的解决方案，只要您在那里没有逻辑，而只需将调用转发到视图模型中的适当方法即可。如果那是我的代码，我会创建直接绑定到 ViewModel 中的命令的自定义命令（同一篇文章中的 DelegateCommand），但您的设计也是 100% 合法的。
I think Josh Smith created a huge confusion in his 2009 article, when he made a point that his code-behind CS files remained mostly empty. MVVM is not about not having code-behind. It is about separation of concerns. If there is any practical rule you should follow, is to make the ViewModel view agnostic (i.e. no reference from the ViewModel to the View. Think having a second unit test implementation of a 'View' for your ViewModel).
This "no code behind" confusion caused very odd structures just to work arround a problem that shouldn't have existed to begin with.
Having code behind in the MainWindow.xaml.cs is perfectly reasonable solution, as long as you don't have logic there, but simply forward the call to an appropriate method in the View Model. If that was my code I would have created custom commands (a la DelegateCommand from the same article) that binds directly to commands in the ViewModel, but your design is 100% legit as well.
前往 Codeplex.com 并查找 Caliburn（或更好的 Caliburn Micro）。它扩展了 WPF，实际上允许调用具有从其他对象拉取的任意参数的方法，并且该方法位于视图模型/控制器中，而无需在代码后面仅使用“挂钩方法”来转发调用。
这些扩展可以做一些很棒的事情，比如提取文本框的值并将其作为参数传递给方法，然后对返回值做出反应 - 就像视图应该做的那样。
您在“stock”wpf 的限制下运行 - 它只能指向后面代码中的方法处理程序，而不考虑参数。替代方案是存在的，甚至来自微软。
Head over to Codeplex.com and look for Caliburn (or better Caliburn Micro). It extends WPF to actually allow calling of methods with arbitrary parameters pulled from other objects and the method being in the view model / controller without having a "hook method" in code behind just fowwarding the call.
The extensions can do wonderfull thignsl ike pull the value of a textbox and pass it as parameter to a method, then react on the return value - much like a view should.
You run in a limitation of "stock" wpf - which simply can only point towards method handlers in code behind without any regards to parameters. Alterantives exist, even from microsoft.