MV*的描述

MVC的调用关系

用户的对View操做之后，View捕获到这个操做，会把处理的权利交移给Controller（Pass calls）；Controller接着会执行相关的业务逻辑，这些业务逻辑可能须要对Model进行相应的操做；当Model变动了之后，会经过观察者模式（Observer Pattern）通知View；View经过观察者模式收到Model变动的消息之后，会向Model请求最新的数据，而后从新更新界面。

优势：

1. 把业务逻辑所有分离到Controller中，模块化程度高。当业务逻辑变动的时候，不须要变动View和Model，只须要Controller换成另一个Controller就好了（Swappable Controller）。
2. 观察者模式能够作到多视图同时更新。

缺点：

1. Controller测试困难。由于视图同步操做是由View本身执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是没法验证的：Controller更新Model的时候，没法对View的更新操做进行断言。
2. View没法组件化。View是强依赖特定的Model的，若是须要把这个View抽出来做为一个另一个应用程序可复用的组件就困难了。由于不一样程序的的Domain Model是不同的。

MVP（Passive View）的调用关系

和MVC模式同样，用户对View的操做都会从View交移给Presenter。Presenter一样的会执行相应的业务逻辑，而且对Model进行相应的操做；而这时候Model也是经过观察者模式把本身变动的消息传递出去，可是是传给Presenter而不是View。Presenter获取到Model变动的消息之后，经过View提供的接口更新界面。

关键点：

1. View再也不负责同步的逻辑，而是由Presenter负责。Presenter中既有业务逻辑也有同步逻辑。
2. View须要提供操做界面的接口给Presenter进行调用。（关键）

对比在MVC中，Controller是不能操做View的，View也没有提供相应的接口；而在MVP当中，Presenter能够操做View，View须要提供一组对界面操做的接口给Presenter进行调用；Model仍然经过事件广播本身的变动，但由Presenter监听而不是View。

优势：

1. 便于测试。Presenter对View是经过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。能够经过Mock一个View对象，这个对象只须要实现了View的接口便可。而后依赖注入到Presenter中，单元测试的时候就能够完整的测试Presenter业务逻辑的正确性。这里根据上面的例子给出了Presenter的单元测试样例。
2. View能够进行组件化。在MVP当中，View不依赖Model。这样就可让View从特定的业务场景中脱离出来，能够说View能够作到对业务逻辑彻底无知。它只须要提供一系列接口提供给上层操做。这样就能够作到高度可复用的View组件。

缺点：

1. Presenter中除了业务逻辑之外，还有大量的View->Model，Model->View的手动同步逻辑，形成Presenter比较笨重，维护起来��比较困难。

MVP（Supervising Controller）

 上面讲的是MVP的Passive View模式，该模式下View很是Passive，它几乎什么都不知道，Presenter让它干什么它就干什么。而Supervising Controller模式中，Presenter会把一部分简单的同步逻辑交给View本身去作，Presenter只负责比较复杂的、高层次的UI操做，因此能够把它当作一个Supervising Controller。

MVVM的调用关系

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哪一部分便可。

优势：

1. 提升可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提升了代码的可维护性。
2. 简化测试。由于同步逻辑是交由Binder作的，View跟着Model同时变动，因此只须要保证Model的正确性，View就正确。大大减小了对View同步更新的测试。

缺点：

1. 过于简单的图形界面不适用，或说牛刀杀鸡。
2. 对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。
3. 数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。