简介
在实际的开发中遇到不同的项目我们可能会选择不同的框架，目前android主要使用三种框架MVC，MVP，MVVM，各有各的用途，今天就来详细介绍下各个框架，以便在今后的开发中都能选择最适合的框架。
MVC
这可能是我们最熟悉的一种框架了，全名是 Model--View--Controller，是模型(model)－视图(view)－控 制器(controller)的缩写，它是用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
视图层(View)
处理界面的显示结果（xml等的布局文件或者是java中动态生成的view）。
控制层(Controller)
起到桥梁的作用，来控制 View 层和 Model 层通信以此来达到分离视图显示和业务逻辑层。（主要为Activity）。
模型层(Model)
处理数据，业务逻辑等（针对业务模型，建立的数据结构和相关的类）。
关键点：
1、View 是把控制权交移给 Controller，自己不执行业务逻辑。
2、Controller 执行业务逻辑并且操作 Model，但不会直接操作 View。
3、View 和 Model 的同步消息是通过观察者模式进行，而同步操作是由 View 自己请求 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
MVP 其实是 MVC 的一种演进版本，它更简单，将 MVC 中的 Controller 改为了 Presenter， View 通过接口与 Presenter 进行交互，降低耦合，方便进行单元测试。
视图层(View)
负责绘制 UI 元素、与用户进行交互(Activity、View、Fragment 都可以做为 View 层)；
模型层(Model)
对数据的操作、对网络等的操作，和业务相关的逻辑处理；
中间处理层（Presenter）：
作为 View 与 Model 交互的中间纽带，处理与用户交互的逻辑。可以把 Presenter 理解为一个中间层的角色，它接受 Model 层的数据，并且处理之后传递给 View 层，还需要 处理 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 业务逻辑的正确性。
2、View 可以进行组件化。在 MVP 当中，View 不依赖 Model。这样就可以让 View 从特定的业务场景中脱 离出来，可以说 View 可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可 以做高度可复用的 View 组件。
缺点：
1、Presenter 中除了业务逻辑以外，还有大量的 View->Model，Model->View 的手动同步逻辑，造成 Presenter 比较笨重，维护起来会比较困难。
MVVM
MVVM 模式（Model--View--ViewModel 模式），和 MVP 模式相比，MVVM 模式用 ViewModel 替换了 Presenter ，其他层基本上与 MVP 模式一致。
视图层(View)
负责绘制 UI 元素、与用户进行交互(Activity、View、Fragment 都可以做为 View 层)；
模型层(Model)
对数据的操作、对网络等的操作，和业务相关的逻辑处理（针对业务模型，建立的数据结构和相关的类，它主要负责网络请求，数据库处理，I/O的操作）；
中间处理层（ViewModel）：
View 的数据模型和MVP中 Presenter 的合体。
MVVM 采用双向绑定（data-binding）：View 的变动，自动反映在 ViewModel，反之亦然， 这种模式实际上是框架替应用开发者做了一些工作（相当于 ViewModel 类是由库帮我们生 成的），开发者只需要较少的代码就能实现比较复杂的交互。MVVM 的调用关系和 MVP 一样。但是，在 ViewModel 当中会有一个叫 Binder，或者是 Data-bindingengine 的东西。以前全部由 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 的。
总结
从MVC到MVP再到MVVM，大方向一直都是在进步，后者都是解决了前者遗留的问题，把前者的缺点优化成了优点，但是进步的同时也暴露了新的缺点。所以实际选择使用哪一种框架也是视项目而定，项目小简单的话不在乎框架就用普通的MVC框架就行，展示型软件业务逻辑大部分在后端就使用MVVM框架，软件中含有大量业务逻辑可以使用MVP框架。
