MVC/MVP/MVVM

1. MVC

MVC全名是Model View Controller，是数据抽象(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

Android中的MVC所对应的职责主要有：

• Model：负责业务逻辑处理；
• View：处理数据显示的部分；
• Controller：传递用户的交互和更新Model的数据。

1.1 Model

其主要对应的是一些DataSource以及DataBean的相关对象，即数据来源。一般数据的来源主要是Sqlite和Webservice, 通过将其封装在repository中，使用时只需调用其接口获取数据即可。

1.2 View

对应的是Android中的layout文件夹中的xml文件，在启动Activity/Fragment的时候都会加载相应的布局文件，使得在试图中显示出我们在xml中定义好的试图。

1.3 Controller

对应的是Activity/Fragment，当Activity/Fragment加载了layout文件后，我们需要在Activity/Fragment中findviewbyid(int)去寻找相对应的view，并对找到的view设置相应的属性以及监听器。而在设置view的属性之前，我们很有可能会先到model中请求一次数据，当数据回调回来后controller就会去更新view了。

1.4 优缺点

优点：

MVC模式, 分离类的UI与业务职责，增加可测试性与可扩展性。Model不引用任何Android类，允许单元测试(Unit Test)。Controller含有View的引用，不引用Android类, 允许单元测试。View满足单一职责原则(SRP)，传递事件至Controller，展示Model数据，不包含业务逻辑，允许UI测试。易于上手，能在不需要考虑太多的情况下快速开发一些小型demo的app。

缺点：

View既依赖于Controller又依赖于Model。在修改UI逻辑时，也需要修改Model，降低架构的灵活性.。View与Model的职责部分重叠，过于耦合。随着业务的扩展controller会变得越来越臃肿和复杂，大大增加了开发人员的维护成本和交接成本，使得后期工作难以展开。

2. MVP

在Android中使用MVC架构，无法完全分离View层与Model层中的UI逻辑与业务逻辑，导致模块耦合，无法全部覆盖测试。因而引入进化版MVP(Model-View-Presenter)架构，在Model层传输数据至View层时，使用Presenter层封装逻辑。Google在Android框架指引中，也采用MVP架构，还添加若干细节。

MVP架构包含三大模块, 即Model, View, Presenter：

• Model: 即数据层, 负责处理业务逻辑, 监听网络与数据库接口.
• View: 即界面(UI)层, 展示数据, 响应用户事件并通知Presenter.
• Presenter: 即展示层, 接收Model的数据, 处理UI逻辑, 并管理View的状态, 根据View层事件提供展示数据.

MVP的Presenter是框架的控制者，承担了大量的逻辑操作，而MVC的Controller更多时候承担一种转发的作用。因此在App中引入MVP的原因，是为了将此前在Activty中包含的大量逻辑操作放到控制层中，避免Activity的臃肿。

2.1 MVC vs MVP

• View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互。而在MVC中View可以与Model直接交互
• 通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。而Controller是基于行为的，并且可以被多个View共享，Controller可以负责决定显示哪个View
• Presenter与View的交互是通过接口来进行的，更有利于添加单元测试。

2.2 优缺点

优点：

1. 模型与视图完全分离，我们可以修改视图而不影响模型；
2. 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
3. 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
4. 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

缺点：

对于小型项目而言，与设计模式类似，会导致过度设计，增加代码量。当处理复杂页面时，Presenter层会包含大量UI逻辑与业务逻辑，非常冗余，并违反单一职责原理.

3. MVVM

MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。

MVVM包含三个模块, Model, View, ViewModel：

Model：即DataModel, 抽象数据源, ViewModel从Model中读取或存储数据；

View：当用户触发响应事件时, 通知ViewModel, 展示提供的数据；

ViewModel：提供View显示的数据流。

3.1 MVVM vs MVP

MVVM与MVP相似, 目标都是分离UI与业务逻辑：

1. Presenter与View强绑定，为View提供展示数据, 是一对一关系；
2. ViewModel提供数据流，供View弱绑定，是一对多关系；
3. Presenter与View相互引用；ViewModel独立于View，View绑定ViewModel引用；
4. View与ViewModel，类似于消费者知道生产者，而生产者只提供数据，并不关心谁消费。

3.2 优势

MVVM的优势是进一步解耦UI逻辑与业务逻辑：

1. View与ViewModel的耦合，弱于View与Presenter的耦合；
2. View仅是ViewModel的消费者，当修改UI时, 不修改ViewModel；
3. 根据业务关注点，创建多个高内聚的View与ViewModel，允许多个页面共享与替换；
4. 彻底分离UI逻辑，使用DataBinding分离UI显示与UI逻辑；
5. View与ViewModel一对多，ViewModel与Model多对多；
6. ViewModel和Model与UI界面完全解耦，进一步提高可测试性。

4. 三者对比

4.1同

如果把这三者放在一起比较，先说一下三者的共同点，也就是Model和View：

• Model：数据对象，同时，提供本应用外部对应用程序数据的操作的接口，也可能在数据变化时发出变更通知。Model不依赖于View的实现，只要外部程序调用Model的接口就能够实现对数据的增删改查。
• View：UI层，提供对最终用户的交互操作功能，包括UI展现代码及一些相关的界面逻辑代码。

4.2 异

三者的差异在于如何粘合View和Model，实现用户的交互操作以及变更通知

1. Controller

   Controller接收View的操作事件，根据事件不同，或者调用Model的接口进行数据操作，或者进行View的跳转，从而也意味着一个Controller可以对应多个View。Controller对View的实现不太关心，只会被动地接收，Model的数据变更不通过Controller直接通知View，通常View采用观察者模式监听Model的变化。

2. Presenter

   Presenter与Controller一样，接收View的命令，对Model进行操作；与Controller不同的是Presenter会反作用于View，Model的变更通知首先被Presenter获得，然后Presenter再去更新View。一个Presenter只对应于一个View。根据Presenter和View对逻辑代码分担的程度不同，这种模式又有两种情况：Passive View和Supervisor Controller。

3. ViewModel

   注意这里的“Model”指的是View的Model，跟MVVM中的一个Model不是一回事。所谓View的Model就是包含View的一些数据属性和操作的这么一个东东，这种模式的关键技术就是数据绑定（data binding），View的变化会直接影响ViewModel，ViewModel的变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互。

参考并感谢

1. Android App的设计架构：MVC,MVP,MVVM与架构经验谈
2. 完全解析Android项目架构
3. android-architecture