c# - MVVM 疯狂 : Commands

Question

我喜欢 MVVM。我不喜欢它，但喜欢它。其中大部分是有道理的。但是，我一直在阅读鼓励您编写大量代码的文章，这样您就可以编写 XAML 而不必在代码隐藏中编写任何代码。

我举个例子。

最近我想将我的 ViewModel 中的命令连接到 ListView MouseDoubleClickEvent。我不太确定该怎么做。幸运的是，谷歌对所有问题都有答案。我找到了以下文章:

• http://blog.functionalfun.net/2008/09/hooking-up-commands-to-events-in-wpf.html
• http://joyfulwpf.blogspot.com/2009/05/mvvm-invoking-command-on-attached-event.html
• http://sachabarber.net/?p=514
• http://geekswithblogs.net/HouseOfBilz/archive/2009/08/27/adventures-in-mvvm-ndash-binding-commands-to-any-event.aspx
• http://marlongrech.wordpress.com/2008/12/13/attachedcommandbehavior-v2-aka-acb/

虽然这些解决方案有助于我理解命令，但也存在问题。上述一些解决方案导致 WPF 设计器无法使用，因为在依赖属性后附加“Internal”的常见黑客攻击； WPF 设计器找不到它，但 CLR 可以。一些解决方案不允许对同一控件执行多个命令。一些解决方案不允许参数。

经过几个小时的试验，我决定这样做:

private void ListView_MouseDoubleClick(object sender, MouseButtonEventArgs e) {
    ListView lv = sender as ListView;
    MyViewModel vm = this.DataContext as MyViewModel;

    vm.DoSomethingCommand.Execute(lv.SelectedItem);
}

那么，MVVM 纯粹主义者，请告诉我这有什么问题？我仍然可以对我的命令进行单元测试。这看起来很实用，但似乎违反了“ZOMG......你的代码隐藏中有代码!!!”的准则。请分享您的想法。

提前致谢。

Answer 1

我认为错误在于纯度要求。设计模式，包括 MVVM，是工具箱中的一个工具，而不是它们自己的目的。如果为了一个经过深思熟虑的案例而打破模型的纯粹性更有意义(并且看起来您显然已经考虑过这种情况)，那么就打破模型。

如果这对您有用，并且您不认为这是过度的维护负担，那么我会说您所做的没有任何问题。我认为您显然已经承担了举证责任，证明这是对您的问题的合理解决方案，尽管纯 MVVM 实现可能是这样。

(我认为这个论点类似于多范式语言的论点。虽然可以应用纯 OO 方法，但有时以更函数式的方式做事更合适。虽然可以应用纯函数式方法，但有时权衡取舍表明 OO 技术非常值得。)