前言

一千个人看待MVVM模式，可能会有一千种看法，笔者在实践中提供自己的理解，供参考。

简介

容笔者做实践讲解时，先介绍下MVC、MVP、MVVM三种模式

MVC

苹果官方提供的MVC版本和后来演变的MVP很像，C层承担了所有逻辑（包括数据处理和UI响应）的交互

image.png

• 优点：View、Model可以重复利用，可以独立使用缺点：
• Controller的代码过于臃肿

为解决 Controller的代码过于臃肿的问题，产生了MVC的变种：

image.png

• 优点：对Controller进行瘦身，将View内部的细节封装，外界不感知View内部的具体实现
• 缺点：View依赖于Model

MVP

MVP和苹果官方的MVC比较相似，不同点在于将原本写在C层的逻辑代码，用Present层进行了沉淀。

image.png

• 优点：
  • 便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。
  • View可以进行组件化。在MVP当中，View不依赖Model，做到对业务逻辑完全无知。只需要提供一系列接口提供给上层操作。
• 缺点：
  • Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

MVVM

MVVM分为三个部分：Model(数据)、View(界面)、ViewModel(数据绑定层)。在MVP的基础上，采用双向绑定（data-binding）的方式进行交互：

image.png

MVVM的实践

从上文对MVVM的描述，我们实践过程中还是发现了一些问题：

• VM通过通知的方式与M层交互，但在实际场景中，会增加很多不明确性。以TableView举例，TableView需要通过vm层reloadData时，不可能VM层用通知的方式来更新Model数据。
• M层的设计存在争议，业界也有大M和小M之争，不同的业务场景可能会采用不同的M层设计
  • 大M：包含数据模型、数据获取和数据操作的ModelService
  • 小M：无逻辑的数据模型

笔者这边做了以下取舍：

• 定义页面级别的上下文context，其包含页面必要参数、VC实例等等，承担MVVM的数据透传
• 容器承担binder角色，绑定VM层和Model层、VM层和View层的关系
• 采用大M方案，以ModelService来承接数据的处理，以减轻VM层的数据处理压力
• 抽象通用的数据处理的协议，根据不同的业务标识注册对应的ModelService实现

（未完待续，代码脱敏后继续书写）