始终在WPF应用程序中使用MVVM,还是替代模式仍然实用/有用？

Question

在Microsoft .NET Architecting Applications for the Enterprise一书中的第374页上,有一个关于表示层模式演变及其对平台影响的图表(图7-14).

除了展示从最初的MVC模式到更现代的变体的演变之外,该图表还显示以下现代模式可以应用于以下技术:

1. Model2(MVC)
   • 仅限网络
2. 被动视图(MVP)
   • 卷筒纸
   • 的WinForms
   • WPF
3. 监督控制器(MVP)
   • 卷筒纸
   • 的WinForms
   • WPF
4. MVVM(演示模型)
   • 仅限WPF

注意:最近没有出现在另一个最近感兴趣的模式是Presenter First(MVP),它被设想为更加适应TDD.

---

根据我的理解,如果使用WPF开发,那么MVVM模式是事实上的选择(类似于Model2用于Web开发).也就是说,似乎没有什么能阻止人们在WPF应用程序中使用Passive View,Supervising Controller或Presenter First.这种方法会导致应用程序无法真正关心前端是WPF,WinForms还是Web.看来这些MVP变体允许更大的灵活性.

但是,针对UI平台无关的灵活性(可能不需要)的目的是使WPF开发变得更加困难并且失去WPF提供的部分功能/功能吗？这么多,成本超过了收益？

换句话说,MVVM是如此之大,以至于人们不应该考虑WPF应用程序中的其他替代方案？

Answer 1

根据WPVM MVVM中包含的文档(一般介绍的第2页)

这种模式的起源是模糊的,但它可能来自Smalltalk应用模型派生模式一样,由Martin Fowler描述的PresentationModel模式.它适用于Expression团队在开发Blend版本1时使用WPF.如果没有WPF特定的方面,Model-View-ViewModel模式与PresentationModel相同.

去Martin的Fowler网站查找Presentation Model我们有这个

与被动视图和监督控制器相比,演示模型允许您编写完全独立于用于显示的视图的逻辑.您也不需要依赖视图来存储状态.缺点是您需要在表示模型和视图之间使用同步机制.这种同步可以非常简单,但它是必需的.分离演示需要更少的同步,而Passive View根本不需要任何同步.

对于我自己的金属切削CAD-CAM应用程序,我使用被动视图.原因是

1. 通过使模拟对象实现视图使测试更容易,从而允许我的软件的绝大部分功能被自动测试
2. 不仅要重用核心模型,还要重用相关类型的金属切削软件的不同视图.
3. 清楚地记录视图和模型之间的交互.
4. 为了摧毁对GUI工具包的任何依赖,因为该软件自1985年以来一直在不断发展,并且看到了底层工具,API甚至语言本身的几个重大变化.

可以通过MVVM,Presentation Model,Supervising Controller模式来处理前三个问题.但只有被动视图解决了#4.

正如Martin Fowler所述,只有被动视图不需要任何同步方法.MVVM是WPF表示模型的实现.您依赖于XAML接口将视图模型中的视图状态与视图本身联系起来.因此,如果稍后您更改UI或其API,那么您的视图模型也将更改.

相比之下,Passive View仅要求新UI元素实现View Interface.它们实际连接的内容并不重要,因为实现正确响应的表单或控件.

但是价格是你在实现视图的新元素时有一个额外的步骤.您必须决定如何将它们呈现给演示者以及抽象级别.它足以杀死某些项目或某些类型的UI,如对话框.

关于MVVM是WPF的问题的简短回答,答案是肯定不是.根据应用程序开发的其他问题,需要考虑这个工具.

Answer 2

@RS康利的回答是对这个主题给出了非常广泛的答案,我同意大多数人的看法.我认为唯一不同的是底线.

MVVM是WPF中95%应用程序的架构.

选择任何其他架构意味着解决一些不是最好的东西.在RS Conley的情况下,Passive View可能是最好的方式,但这远非正常情况.

作为理解MVVM如何更好的一种方式,让我们看看他在使用PassiveView方法时会失去什么.

可维护性

在Passive View中,ViewModel知道IView,这意味着不保留SRP(单一责任原则).PassiveView中的Controller直接与Model和View进行交互,因此做了两件完全不同的事情!.

在MVVM下,ViewModel是应用程序的核心,只有一个问题,即包含应用程序的状态和逻辑.这种代码的可维护性非常优于PassiveView,MVP或MVC.

确实,PassiveView在Automated Tests Coverege方面更胜一筹,但恕我直言,代码的良好可维护性更为重要.可测试性有助于确保不会破坏代码,而可维护性可帮助您不要构建有问题的代码.

在可维护性方面,MVVM和PresentationModel是以前的UI架构的演变,这是因为SRP原则非常严格.在MVVM中编写足够的代码,你就会明白我的意思.

可混合性

MVVM非常强大的另一个特性是Blendability.由于所有应用程序状态都保留在ViewModel中,因此很容易伪造数据用于设计时间,这可以极大地提高生产率.这在PassiveView,MVP或MVC中是不可能创建的,因为在所有这些体系结构中,控制器必须主动将数据放入视图中.在MVVM中,数据只是"跳转"到View,因此可以被模拟.

可测性

这确实是PassiveView优于MVVM的地方.如果100%单元测试覆盖UI对您来说至关重要,那么这是一个大问题.然而,在大多数情况下,MVVM允许的覆盖范围绰绰有余,并且您通常会使用常规UI测试添加另一层测试(您最终也会在PassiveView中执行此操作).

我认为可测试性在三个功能中不太重要.按重要性排序,它的可维护性,可混合性和可测试性.

MVVM在哪里不是正确的选择？

去年我参加了大约15个WPF和Silverlight项目,所有这些项目都适合MVVM.我认为在表示逻辑非常大的地方,例如在游戏中,MVVM可能不是正确的选择.除了游戏之外,我无法想到一个与MVVM不相称的应用程序类别,除了RS Conley提到的特殊情况.