问总是在WPF应用程序中使用MVVM，或者替代模式仍然实用/有用吗？

EN

@RS Conley的答案是对这个主题进行了非常广泛的探讨，我同意大多数人的看法。我认为唯一不同的是底线。

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

选择任何其他架构都意味着满足于一些你所能得到的最好的东西。在RS Conley的情况下，被动视图可能是最好的方式，但这是远离的正常情况。

为了理解MVVM是如何变得更好的，让我们看看他在使用PassiveView方法时会失去什么。

Maintainability

在被动视图中，ViewModel知道IView，这意味着不保留SRP (单一责任原则)。PassiveView中的控制器直接与模型和视图交互，因此做的是两件完全不同的事情！

在虚拟机中，作为应用程序核心的ViewModel只有一个关注点，那就是包含应用程序的状态和逻辑。这类代码的可维护性确实优于PassiveView、MVP或MVC。

当涉及到自动化测试覆盖时，PassiveView确实更好，但是，代码的良好可维护性要重要得多。可测试性帮助您确保不会破坏代码，而可维护性帮助您从一开始就不会构建有问题的代码。

当涉及到可维护性时，MVVM和PresentationModel是对以前UI架构的改进，这是因为SRP原则被严格遵守。用MVVM编写足够的代码，你就会明白我的意思了。

可混合性

MVVM真正强大的另一个特性是可混合性。由于所有应用程序状态都保存在ViewModel中，因此很容易在设计时伪造数据，从而极大地提高了生产率。这是不可能在PassiveView、MVP或MVC中创建的，因为在所有这些架构中，控制器必须主动地将数据放在视图中。在MVVM中，数据只是“跳转”到视图中，因此可以被模拟。

可测试性

这确实是PassiveView优于MVVM的地方。如果UI的100%单元测试复盖率对你来说至关重要，那么它就是一件大事。然而，在大多数情况下，MVVM允许的覆盖范围已经足够了，您通常会使用常规UI测试添加另一层测试(您最终也会在PassiveView中进行测试)。

我认为可测试性是这三个特性中不太重要的一个。按重要性排序，它是可维护性、可混合性和可测试性。

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

去年我参与了大约15个WPF和Silverlight项目，所有这些项目都非常适合MVVM。我认为在表示逻辑非常庞大的地方，比如在游戏中，MVVM可能不是正确的选择。除了游戏，除了RS Conley提到的特殊情况外，我真的想不出有什么应用程序类别不适合MVVM。

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

这个模式的起源是模糊的，但它可能来自Smalltalk ApplicationModel模式，就像Martin Fowler描述的PresentationModel模式一样。Expression团队在开发Blend的版本1时对其进行了调整，以供WPF使用。没有特定于WPF的方面，模型-视图-视图模型模式与PresentationModel是相同的。

访问Martin's Fowler的网站，在Presentation Model上查找，我们有以下内容

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

对于我自己的金属切割CAD-CAM应用程序，我使用Passive View。其原因是

1. 通过让模拟对象实现视图来简化测试，从而允许自动测试我的软件的绝大多数功能
2. 不仅可以重用核心模型，还可以为相关类型的金属切削软件重用不同的视图。
3. 清楚地记录视图和模型之间的交互。
4. 销毁对图形用户界面工具包的任何依赖，因为该软件自1985年以来一直在持续开发，并且在底层工具、API甚至语言本身方面发生了几个重大变化。

<代码>G215

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

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

相比之下，被动视图只要求新的UI元素实现View接口。它们实际连接到什么并不重要，因为实现的窗体或控件也会正确响应。

但代价是在实现视图的新元素时需要额外的一步。您必须决定如何将它们呈现给演示者，以及在哪个抽象级别上。对于某些项目或某些类型的UI (如对话框)，它已经足够了。

关于MVVM是WPF的方式的问题，简短的回答是不是它不是。它是一个需要根据围绕应用程序开发的其他问题来考虑的工具。

在过去的几个月里，我一直致力于使用WP7 (Silverlight) MVVM应用程序来实现MVP。我相信我已经想出了一个很好的解决方案，它充分利用了这两个领域的优势。缺点是有相当多的“脚手架”代码。优点是一个最有价值的框架，其中模型和演示者层应该在WP7、WM和安卓(给定MonoDroid)之间重用。

我使用了这里描述的MVP-VM - http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html作为我设计的基础。

模型就是模型，不需要任何说明。它包含数据类、业务逻辑和服务，并且不引用任何特定于UI的内容。

Presenter和View界面遵循被动视图模式。

视图接口主要由事件、一些属性和一些方法组成。在Presenter和View之间传递的所有内容都不是特定于UI的。

视图实现是PhoneApplicationPage (或WPF form)、PageViewModel和ViewFacade的组合。

ViewFacade才是真正实现视图接口的对象。它负责协调页面和ViewModel。它从页面中冒泡事件，使它们中的大多数异步触发，演示者捕获这些事件。它还将任何特定于UI的事件参数转换为非UI参数。从Presenter到ViewFacade的任何内容都将检查UI线程安全性，并正确调用。属性通常是数据，并传递给ViewModel。

将视图接口实现(ViewFacade)与实际的UI类(页面、表单等)分开有助于保持视图三元组类之间的职责不同。例如，ViewFacade的主要用途之一是作为线程同步发生的层。

页面/ ViewModel的执行方式与您通常一样，但是，命令是通过ViewFacade向演示者冒泡的事件。

优势

MVP设计和平台间的可重用性。

使用MVVM轻松绑定数据。

IMO，MVP更符合逻辑，更容易概念化。

的劣势

页面事件和ViewFacade事件、ViewModel属性和ViewFacade属性之间的代码重复。

简单的情况下可能会有比实际需要多得多的代码。

最后，你不得不问自己，MVP是否值得你付出额外的努力。更快的开发周期比跨平台的可重用性和增强的可测试性更重要吗？