MVC / MVP / MVVM 架构模式

Android架构，即为开发Android时使用的架构。Android的开发一般分为三部分：UI逻辑，业务逻辑和数据操作逻辑。

Android架构，就是为了更好地协调这三者的关系。达到：

• 各模块高内聚低耦合的状态，方便进行团队分工合作开发。

• 代码思路清晰，提高代码的可维护性与可测试性。

• 减少样板代码，提高开发效率，减少开发错误。

MVC

Android上的MVC架构我认为是来源于web开发的SpringMVC，MVC全名为Model-View-Controller，图解如下：

0

View：负责与用户交汇，显示界面。

Controller：负责接收来自view的请求，处理业务逻辑。

Model：负责数据逻辑，网络请求数据以及本地数据库操作数据等。

在MVC架构中，Controller是业务的主要承载者，几乎所有的业务逻辑都在Controller中进行编写。而View主要负责UI逻辑，而Model是数据逻辑，彼此分工。

MVC的本质就是按照UI逻辑、业务逻辑、数据操作逻辑不同的职责分三大模块，彼此分工。

在Android中，View一般使用xml进行编写，但xml的能力不全面，需要Activity进行一些UI逻辑的编写，因而MVC中的V即为xml+Activity。Model数据层，在Android中负责网络请求和数据库操作，并向外暴露接口。Controller是争议比较多的写法：一种是直接把Activity当成Controller；一种是独立出Controller类，进行逻辑分离。比较符合MVC思想的笔者认为是后者。因为前者直接在Activity中进行书写业务逻辑就会和UI逻辑混合在一起了，达不到模块分工的效果。

优点：简单。他不需要写很多的代码来让代码解耦，这在小型项目非常有用。小型项目总体的代码就不多，所以这样可以提高开发效率。

缺点：

几乎所有的业务逻辑代码都在Controller中进行，会导致非常臃肿，降低项目的可测试性与可维护性。

View直接持有Controller和Model实例，不同职责的代码进行耦合，导致代码耦合性高，模块分工不清晰。

改进方向：

对模块进行更加彻底的分离，不要让View和Model直接联系。对Controller进行减压。

MVP

相比MVC，MVP的更加的完善。MVP全名是Model-View-Presenter。图解如下：

0

• View：UI模块，负责界面显示和与用户交汇。

• Presenter：负责业务逻辑，起着连接View和Model桥梁的作用。

• Model：专注于数据操作逻辑。

MVP 和 MVC 的区别很明显就在这个Presenter中。为了解决MVC中代码的耦合严重性，把业务逻辑都抽离到了Presenter中。这样View和Model完全被隔离，实现了单向依赖，大大减少了耦合度。View和Prensenter之间通过接口来通信，只要定义好接口，那么团队可以合作同时开发不同的模块，同时不同的模块也可以进行独立测试。也因各模块独立了，所以要只要符合接口规范，即可做到动态更换模块而不需要修改其他的模块。

在Android中，需要让Activity提供控件的更新接口，Prensenter提供业务逻辑接口，Activity持有Presenter的实例，Presenter持有Activity的弱引用（不用直接引用是为了避免内存泄露），Activity直接调用Presenter的方法更新界面，Presenter去Model获取数据之后，通过View的接口更新View。

0

不同的View可以通过实现相同的接口来共享Prensenter。Prensenter也可以通过实现接口来实现动态更换逻辑。Model是完全独立开发的，向外暴露的方法参数中含有callBack参数，可以直接调用callBack进行回调。

优点：

• MVP通过模块职责分工，抽离业务逻辑，降低代码的耦合性

• 实现模块间的单向依赖，代码思路清晰，提高可维护性

• 模块间通过接口进行通信，降低了模块间的耦合度，可以实现不同模块独立开发或动态更换

缺点：

• 过度设计导致接口过多，编写大量的代码来实现模块解耦，降低了开发效率

• 并没有彻底进行解耦，Prensenter需要同时处理UI逻辑和业务逻辑，Prensenter臃肿

MVVM

MVVM和上面两种架构模式一样都是一种架构思想，只是谷歌推出了jetpack架构组件来让我们更好的使用这种架构模式。

MVVM，全名为Model-View-ViewModel。

0

• View：和前面的MVP、MVC中的View一样，负责UI界面的显示以及与用户的交汇。

• Model：同样是负责网络数据获取或者本地数据库数据获取。

• ViewModel：负责存储View的数据映像以及业务逻辑。

MVVM的View和Model和前面的两种架构模式是差不多的，重点在ViewModel。ViewModel通过将数据和View进行绑定，修改数据会直接反映到View上，通过数据驱动型思想，彻底把MVP中的Presenter的UI操作逻辑给去掉了。而ViewModel是绑定于单独的View的，也就不需要进行编写接口了。但ViewModel中依旧有很多的业务逻辑，但是因为把View和数据进行绑定，这样可以让View和业务彻底的解耦了。View可以专注于UI操作，而ViewModel可以专注于业务操作。因而MVVM通过数据驱动型思想，彻底把业务和UI逻辑进行解耦，各模块分工职责明确。

缺点：

MVVM的ViewModel依旧很臃肿。

MVVM需要学习数据绑定框架，具有一定的上手难度。

适合android开发的MVVM架构模式：

0

简单的解析：

View对应的就是Activity和Fragment，在这里进行UI操作。

ViewModel中包含了LiveData，这是一种可观察数据类型框架。View通过向LiveData注册观察者，当LiveData发生改变时，就会直接调用观察者的逻辑把数据更新到View上。

ViewModel完全不需要关心UI操作，只需要专注于数据与业务操作。

Repository代表了Model层，Repository对ViewModel进行了减压，i把业务操作般到了Repository中，避免了ViewModel臃肿。

Repository对请求进行判断是要到本地数据库获取还是网络请求获取分别调用不同的模块。