再谈MV*(MVVM MVP MVC)模式的设计原理—封装与解耦

精炼并增补于：界面之下：复原真实的MV*模式

图形界面的应用程序提供给客户可视化的操作界面，这个界面提供给数据和信息。客户输入行为（键盘，鼠标等）会执行少量应用逻辑，应用逻辑（application logic）可能会触发肯定的业务逻辑（business logic）对应用程序数据的变更，数据的变更自然需要客户界面的同步变更以提供最精确的信息。

在开发应用程序的时候，以求更好的管理应用程序的复杂性，基于职责分离（Speration of Duties）的思想都会对应用程序进行分层。在开发图形界面应用程序的时候，会把管理客户界面的层次称为View，应用程序的数据为Model（注意这里的Model指的是Domain Model，这个应用程序对需要处理的问题的数据笼统，不包含应用的状态，可以简单了解为对象）。Model提供数据操作的接口，执行相应的业务逻辑。

有了View和Model的分层，那么问题就来了：View如何同步Model的变更，View和Model之间如何粘合在一起?

MV*模式处理什么问题

MV*就是实现了领域模型数据和UI层的解耦。

MVC、MVP、MVVM对其解耦的思路的不同。从历史的角度来看，MVC、MVP和MVVM是一种进化的关系。但是鉴于项目的规模以及模式实现的方式不同，不同的MV*模式各有其优点和缺点，难分孰好孰坏。

但是业界越来越认为：MVVM是前台领域最好的MV*模式。Angular、Vue是MVVM模式典范

MVC的依赖关系

MVC出了把应用程序分成View、Model层，还额外的加了一个Controller层，职责为进行Model和View之间的协作（路由、输入预解决等）的应用逻辑（application logic）。

Model主要是与业务数据有关。

View是应用程序数据的可视化表示。

Controller管理应用程序中Model和View之间的逻辑和协调。

客户对View的输入等操作并不会在View的相关板块中解决逻辑，而是由Controller层取得这些操作（所谓的Pass Call），并由Controller层对这些操作中的数据经过应用逻辑的操作，而后在调用Model层的接口，将数据交给Model层。Model层执行与业务逻辑相关的操作，并升级数据。Model和View通过观察者模式联络在一起，即View是Model的观察者，当Model数据变动之后，通知View层进行数据升级。

MVC优点

把业务逻辑一律分离到Controller中，板块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只要要Controller换成另外一个Controller就行了（Swappable Controller）。

观察者模式可以做到多视图同时升级。

MVC缺点

Controller测试困难。由于视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的：Controller升级Model的时候，无法对View的升级操作进行断言。

View无法组件化。View是强依赖特定的Model的，假如需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。由于不同程序的的Domain Model是不一样的

MVP模式

MVP比起MVC模式，它的特点很显著。MVP中M和V之间的依赖关系被消除了。

在MVC中，M和V之间通过观察者模式依赖。这种依赖关系在MVP中被转移到M和P层中。这样一来P层必需通过肯定的机制通知V层进行数据的升级。所以MVP模式中V层中提供了供P层调用的接口。P层作为观察者取得数据变化是，将调用V层的接口将变化反映到V层中。

在MVP中：

Model层仍然是主要与业务数据有关。、

View仍然是应用程序的可视化表示，但是在MVP中它对领域数据（Model层）完全无知，View不再负责同步的逻辑，而是由Presenter负责。Presenter中既有应用程序逻辑也有同步逻辑。所以比起MVC中View层更轻了。但是，View需要提供操作界面的接口给Presenter进行调用

Presenter层比较重，它不仅调用Model的接口，也调用View的接口。而且需要作为观察者取得Model的数据升级。

MVP（Passive View）的调用关系

MVP（Passive View）优点

便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只要要实现了View的接口就可。而后依赖注入到Presenter中，单元测试的时候即可以完整的测试Presenter应用逻辑的正确性。这里根据上面的例子给出了Presenter的单元测试样例。

View可以进行组件化。在MVP当中，View不依赖Model。这样即可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务完全无知。它只要要提供一系列接口提供给上层操作。这样即可以做到高度可复用的View组件。

MVP（Passive View）缺点

Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

MVP（Supervising Controller）

Supervising Controller模式中，Presenter会把一部分简单的同步逻辑交给View自己去做，Presenter只负责比较复杂的、高层次的UI操作，所以可以把它看成一个Supervising Controller。

由于Supervising Controller用得比较少,MVVM可以看作是一种特殊的MVP（Passive View）模式，或者者说是对MVP模式的一种改良。

MVVM的依赖

Model-View-ViewModel模式中，M层数据的变化不是通过观察者模式通知到V层的（即没有M和V的依赖），也不是通过VM层调用V层的接口将数据传递给V层的（这意味着客户代码不需要手动升级V层）。而是通过在VM层实现一个特殊的binder，将数据从M层直接绑定到V层。这样ViewModel层理解Model层，View层理解ViewModel层。

ViewModel充任了一个数据转换器的作用。它将Model信息转换为View信息，还将命令从View传递到Model。在这里，View可以访问ViewModel,ViewModel可以访问Model。

MVVM的调用关系和MVP一样。但是，在ViewModel当中会有一个叫Binder，或者者是Data-binding engine的东西。以前一律由Presenter负责的View和Model之间数据同步操作交由给Binder解决。你只要要在View的模版语法当中，指令式地公告View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model升级的时候，Binder会自动把数据升级到View上去，当客户对View进行操作（例如表单输入），Binder也会自动把数据升级到Model上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地了解为一个模版引擎，但是会根据数据变更实时渲染。

MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作，而是交由框架所提供的Binder进行负责。只要要告诉Binder，View显示的数据对应的是Model哪一部分就可。

MVVM优点

双向绑定技术，当Model变化时，View-Model会自动升级，View也会自动变化。很好做到数据的一致性，不用担心，在板块的这一块数据是这个值，在另一块就是另一个值了。所以 MVVM模式有些时候又被称作：model-view-binder模式。

提高可维护性。处理了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。

简化测试。由于同步逻辑是交由Binder做的，View跟着Model同时变更，所以只要要保证Model的正确性，View就正确。大大减少了对View同步升级的测试。

MVVM缺点

过于简单的图形界面不适用，或者说牛刀杀鸡。

对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。

数据绑定的公告是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。

一个大的板块中model也会很大，尽管使用方便了也很容易保证了数据的一致性，当时长期持有，不释放内存就造成了花费更多的内存。

数据双向绑定不利于代码重用。用户端开发最常用的重用是View，但是数据双向绑定技术，让你在一个View都绑定了一个model，不同板块的model都不同。那就不能简单重用View了。