传统的MVVM实现是否毫无意义？我正在创建一个新的应用程序，我考虑了Windows窗体和WPF.我 Select WPF是因为它经得起future 的考验，并且提供了很大的灵活性.使用XAML，代码更少，更容易对UI进行重大更改.
由于WPF的 Select 是显而易见的，我想我也可以使用MVVM作为我的应用程序架构，因为它提供了可混合性、分离问题和单元可测试性.从理论上讲，它看起来很漂亮，就像UI编程的圣杯.这一短暂的冒险；然而，却变成了一件真正令人头疼的事情. 不出所料，在实践中，我发现我用一个问题换了另一个问题.我往往是一个痴迷的程序员，因为我想用正确的方式做事，这样我就可以得到正确的结果，并有可能成为一名更好的程序员.MVVM模式刚刚没有通过我的生产力测试，而且刚刚变成了一个讨厌的大麻烦！
一个明显的例子是添加对Modal对话框的支持.正确的方法是打开一个对话框，并将其绑定到视图模型.要让它发挥作用是很困难的.为了从MVVM模式中获益，您必须将代码分布在应用程序各层的多个位置.您还必须使用深奥的编程 struct ，如模板和Lamba表达式.让你目不转睛地盯着屏幕挠头的东西.正如我最近发现的那样，这使得维护和调试成为等待发生的噩梦.我有一个关于框工作正常，直到我得到一个异常，我第二次调用它，说它不能再次显示对话框，一旦它被关闭.我必须为对话窗口添加一个关闭功能的事件处理程序，在它的IDialogView实现中添加另一个事件处理程序，最后在IDialogViewModel中添加另一个事件处理程序.我以为MVVM会把我们从这种奢侈的黑客攻击中解救出来！
有好几个人对这个问题有着相互竞争的解决方案，他们都是黑客，没有提供一个干净、易于重用、优雅的解决方案.大多数MVVM工具包都掩盖了对话框，当它们处理对话框时，它们只是警告框，不需要自定义界面或视图模型.
我打算放弃MVVM视图模式，至少放弃它的正统实现.你怎么认为？如果你有麻烦，值得吗？我只是一个不称职的程序员，还是MVVM不像人们所宣传的那样？