Android MVVM 解读 2.MVC, MVP, MVVM

Android MVVM background info

包含的信息

1. MVC, MVP, MVVM的介绍
2. MVC, MVP, MVVM的区别

1. MVC, MVP, MVVM的介绍

MVC, MVP和MVVM的区别和联系,是一个老生常谈的问题, 这里也不过多的进行描述

可以先查看下以下的两个链接:

MVC，MVP 和 MVVM 模式如何选择？
你真的理解了MVC, MVP, MVVM吗？

其中第一篇文章是比较偏理论的分析, 第二篇文章中,在介绍时,包含了一些实际的案例

看完这两篇文章,可以总结如下:

1.1 MVC

1.1.1 类图

MVC类图

1.1.2. 活动图

MVC活动图

1.1.3. 依赖关系

1. View 持有Controller和Model

   • 持有Controller用于向Controller发送命令,比如点击UI上的button时,触发的事件
   • 持有Model,是用于向Model注册监听Model变化的Observer

2. Controller 持有Model, 在Controller收到View的命令后,处理相关的逻辑后,向Model发送事件

3. Model 不持有Controller,也不持有View, 在收到命令后,执行命令,并且向注册自身监听器的对象发送事件,此处的监听器对象是View

1.1.4 优缺点总结(来自: https://zhuanlan.zhihu.com/p/38108311)

1. 优点

   1、把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了（Swappable Controller）。
   2、观察者模式可以做到多视图同时更新。

2. 缺点

   1、Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。
   2、View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的.

1.2 MVP

1.2.1. 类图

MVP Class Diagram

1.2.2. 活动图

MVP Activity

1.2.3 依赖关系

1. View持有Presenter

   • 持有Presenter, 用于向Presenter发送命令

2. Presenter持有View和Model

   • Presenter持有Model, 用于向Model发送命令,并且接收Model的回调通知
   • Presenter持有View,用于通知更新UI

3. Model即不持有Presenter,也不持有View

   • 在收到命令后,执行结束后,通知callback回调或者在监听注册的基础上通知

1.2.4 优缺点总结(来自: https://zhuanlan.zhihu.com/p/38108311)

1. 优点

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

2. 缺点

1、Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

1.3 MVVM

1.3.1 类图

MVVM 类图

1.3.2 活动图

在这里插入图片描述

1.3.3 依赖关系

1. DataBinding 持有View具体的多个具体的View, DataBinding持有ViewModel

   • DataBinding 是一个框架, 在View中进行声明,针对某一个具体的View和具体的ViewModel的dataBinding便可以生成
   • 通过在View中的声明, DataBinding可以生成View的事件,自动绑定到ViewModel的调用方法
   • 通过在View中的声明, DataBinding可以生成ViewModel的具体field的观察者,在ViewModel的field发生变化后,回调给DataBinding,dataBinding的观察者,自动通知更新到View的UI上

2. View 持有DataBinding

   • View通过声明,便关联到某一个具体的ViewModel
   • View通过声明,自动生成一个和View,以及声明的ViewModel相关的DataBinding
   • View在声明后,初始化时,找到DataBinding,然后给DataBinding,绑定ViewModel,便可以运作

3. ViewModel 持有Model, 不持有DataBinding和View

   • ViewModel暴露的方法中,在方法被调用时,ViewModel调用Model的方法,Model的数据变更后,主动引起ViewModel的数据变更,而ViewModel的数据变更,便会被DataBinding监听到,进而引起UI的变化

4. Model 不持有任何的模型

   • Model的方法返回的是可被observe的数据,ViewModel可以持有此observe数据,作为数据源,或者根据此数据源再包裹一个observe作为引用不变的数据源,方便DataBinding引用

1.3.4 优缺点总结(来自: https://zhuanlan.zhihu.com/p/38108311)

1. 优点

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

2. 缺点

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

2. MVC, MVP, MVVM的区别

2.1 演进

1. 从MVC 到 MVP , 主要解决了三者相互依赖的问题
2. 从MVP 到 MVVM, 主要解决了Presenter到View的手动更新的问题, 但是因此却带来了一个新的框架DataBinding的部分,学习成本增加了

2.2 选择使用篇

1. 小型的UI工程,其实可选用MVP, 如果选用MVVM的话,需要引用新的框架DataBinding,学习成本比较高
2. 对于稍微偏中型的UI工程,可选用MVVM
3. 对于大型复杂的UI界面,是需要将大型的UI界面,进行模块的拆分,拆分后,可使用MVVM,或者MVP