我喜欢MVVM。我不喜欢它，但是喜欢它。大部分都是有道理的。但是，我一直在阅读鼓励您编写大量代码的文章，以便您可以编写 XAML，而不必在代码隐藏中编写任何代码。
让我举一个例子。
最近，我想将 ViewModel 中的命令连接到 ListView MouseDoubleClickEvent。我不太确定该怎么做。幸运的是，谷歌对所有问题都有答案。我找到了以下文章：
- http://blog.functionfun.net/2008/09/hooking-up-commands-to-events-in-wpf.html 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://joyfulwpf.blogspot.com/2009/05/mvvm-invoking-command-on-attached-event.html
- http://sachabarber.net/?p=514 http://sachabarber.net/?p=514
- Link https://web.archive.org/web/20201027180030/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/ 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...你的代码隐藏中有代码!!!!”的准则。请分享您的想法。
提前致谢。
我认为错误在于纯度要求。设计模式（包括 MVVM）是工具箱中的一个工具，而不是其本身的目的。如果对于经过深思熟虑的案例来说，打破模型的纯粹性更有意义（并且显然您已经考虑过这种情况），那么就打破模型。
如果这对您有用，并且您不认为这是过度的维护负担，那么我会说您所做的一切没有任何问题。我认为您显然已经承担了举证责任，证明这是对您的问题的合理解决方案，无论纯 MVVM 实现是什么。
（我认为这个论点类似于多范式语言的论点。虽然可以应用纯 OO 方法，但有时以更函数式的方式做事更合适。虽然可以应用纯函数式方法，但有时权衡表明 OO技术比花时间更值得。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
