前言
一千个人看待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实现
（未完待续，代码脱敏后继续书写）
