MVC、MVP、MVVM

1、MVC 模式

MVC（Model-View-Controller，模型-视图-控制器）用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，无须重新编写业务逻辑。Android中MVC的角色定义如下。

模型层（Model）：针对业务模型，建立的数据结构和相关的类，可以理解为Model。Model是与View无关，而与业务相关的。
视图层（View）：一般采用 XML 文件或者 Java 代码进行页面的描述，也可以使用 JavaScript+HTML 等方式作为View层。
控制层（Controller）：Android 的控制层通常在 Activity、Fragment 或者由它们控制的其他业务类中

MVC简单来说就是通过 Controller 来操作 Model 层的数据，并且返回给 View 层展示，如下图所示

MVC 框架模式.png

Android中 MVC 的优点：

业务逻辑全部分离到 Controller 中，模块化层度高
观察者模式可以做到多视图同时更新

Android中 MVC 的缺点：

Activity 并不是一个标准的 MVC 模式中的 Controller，它的首要职责是加载应用的布局和初始化用户界面，接受并处理来自用户的操作请求，进而做出响应。随着界面及其逻辑的复杂度不断提升，Activity 类的职责不断增加，以至变得庞大臃肿。
View 层和 Model 层相互耦合，不易开发和维护。

2、MVP模式

MVP（Model-View-Presenter）是 MVC 的演化版本

Model：主要提供数据的存取功能。Presenter 需要通过 Model 层来存储、获取数据。
View：负责处理用户事件和视图部分的展示。在Android中，它可能是Activity、Fragment类或者某个 View控件。
Presenter：作为View和Model之间沟通的桥梁，它从Model层检索数据后返回给View层，使得View和Model之间没有耦合。

在MVP里（如下图所示），Presenter 完全将Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter 与具体的 View 是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更 View 时可以保持Presenter的不变，这点符合面向接口编程的特点。View 只应该有简单的 Set/Get 方法，以及用户输入和设置界面显示的内容，除此之外就不应该有更多的内容。决不允许 View 直接访问 Model，这就是其与 MVC 的很大不同之处。

MVP 框架模式.png

MVP优点：

模型与视图完全分离，可以修改视图而不影响模型
可以更高效的使用模型，因为所有的交互都在 Presenter 内部
可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性很有用，因为视图的变化总是比模型的变化频繁
把逻辑放在 Presenter 中，就可以脱离用户接口来测试这些逻辑（单元测试）

MVP缺点

Presenter 作为桥梁协调 View 和 Model，会导致 Presenter 变得很臃肿，维护比较困难

3、MVVM 模式

MVVM（Model-View-ViewModel）将Presenter 改为ViewModel，和MVP类似，不同的是 ViewModel 跟Model 和 View 进行双向绑定：当View 发生改变时，ViewModel 通知 Model 进行更新数据；同理Model数据更新后，ViewModel 通知 View 更新。MVVM 结构图如下图所示：

MVVM 模式.png

MVVM 优点：

低耦合。视图（View）可以独立于 Model 变化和修改，一个ViewModel 可以绑定到不同的“View”上，当 Model 变化的时候 View 也可以不变
可重用性。可以把一些视图逻辑放在一个 ViewModel 中，让很多View重用这段逻辑视图
独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用 Expression Blend 可以很容易设计界面并生成XML代码
可测试。界面元素是比较难测试的，而现在测试可以针对ViewModel来写。
提高可维护性。解决了MVP大量的手动 View 和 Model 同步的问题，提供双向绑定机制。提高了代码可维护性。

MVVM 缺点：

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