MV*开发模式

Model(模型)：业务逻辑相关的数据对象—对数据进行操作
view(视图)：展示给用户看的，是实现与用户的交互功能

MVC

Controller(控制器)：对视图中每发生的一种事件，都写一段代码来表示修改model(模型)中的某一个数据

当用户通过view层进行了数据的修改或触发了事件时，MVC通过controller(控制器)向model层提交请求操作，而controller会对来自view
的数据进行预处理，决定使用model的哪个接口，然后由model执行相应的逻辑后，将数据返回给view层

优点

1. 多个视图能共享一个模型，同一个模型可以被不同的视图重用，大大提高了代码的可重用性。
2. 由于MVC的三个模块相互独立，在其中改变一个，其他两个可以保持不变，这样可以把耦合降得很低，这样可以使开发人员可以只关注整个系统中的某一层
3. 控制器提高了应用程序的灵活性和可配置型。控制器可以用来连接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段

缺点

1. 增加了系统结构的实现的复杂性
2. 视图与控制器之间的联系过于紧密，视图如果没有控制器的存在，能够做的事情少之又少，这样视图就很难独立应用了
3. 视图对模型的数据的访问效率过低，因为之间需要多次的调用
4. View无法组件化，View依赖于特定的Model，如果需要把这个View抽出来用在下一个应用程序复用就比较困难了

MVP

Presenter(接口):与MVC相同

但是当view进行数据操作之后，不再是将数据传递给controller了而是传递给了presenter层，当presenter预处理之后，将view的数据
出传递给model层时，model层运行逻辑之后不再是直接将返回的数据返回给view层了，而是通过presenter的view接口返回给view层

优点

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

缺点

1. 代码量会一些，实现的难度也会增加一些

MVVM

view-model(视图模型):它是将"数据模型数据双向绑定"的思想作为核心

ViewModel就是View与Model的连接器，View与Model通过ViewModel实现双向绑定。当view层执行操作时，直接响应绑定在model层的事
件，当model层逻辑执行完成后，将数据通过ViewModel直接返回给view层

优点

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

缺点

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