正统的MVVM实现是没有意义的吗？我正在创建一个新的应用程序,我考虑了Windows窗体和WPF.我之所以选择WPF,是因为它具有前瞻性,并提供了很大的灵活性.使用XAML的代码更少,更容易对UI进行重大更改.
由于WPF的选择是显而易见的,我认为我可以使用MVVM作为我的应用程序架构,因为它提供了可混合性,分离问题和单元可测试性.从理论上讲,它看起来很像UI编程的圣杯.这个简短的冒险; 然而,已经变成了一个真正的头痛.正如在实践中所预期的那样,我发现我已将一个问题换成了另一个问题.我倾向于成为一个强迫性的程序员,因为我想以正确的方式做事,这样我才能获得正确的结果,并可能成为更好的程序员.MVVM模式刚刚落后于我对生产力的考验,刚刚变成了一个令人讨厌的大黑客!
明显的例子是添加对模态对话框的支持.正确的方法是建立一个对话框并将其绑定到视图模型.让这个工作很难.为了从MVVM模式中受益,您必须在应用程序的各个层中的多个位置分发代码.您还必须使用深奥的编程结构,如模板和lamba表达式.让你盯着屏幕挠挠头的东西.正如我最近发现的那样,这使得维护和调试成为一场噩梦.我有一个关于盒子正常工作,直到我第二次调用它时出现异常,说它一旦关闭就无法再显示对话框.我必须为对话框窗口添加一个关闭功能的事件处理程序,在IDialogView实现中添加另一个,最后在IDialogViewModel中添加另一个.我以为MVVM会让我们免于这种奢侈的hackery!
有几个人为这个问题提供竞争解决方案,他们都是黑客,并没有提供一个干净,易于重复使用的优雅解决方案.大多数MVVM工具包都会掩盖对话框,当它们确实解决它们时,它们只是不需要自定义接口或视图模型的警报框.
我打算放弃MVVM视图模式,至少是它的正统实现.你怎么看？如果你有任何问题,是否值得为你带来麻烦？我只是一个不称职的程序员,还是MVVM不是它被炒作的东西？