iOS MVC、MVP、MVVM

MVC模式

MVC模式，即Model-View-Controller。它是苹果公司官方推荐的 App 开发架构，也是一般开发者最先遇到、最经典的架构。 图下所示的是 MVC架构的示意图。

image.png

上图持有关系为Controller是同时持有View跟Model的；

1. 当View发生交互事件时，会通过action通知到Controller，Controller收到之后会去更新Model层的数据
2. 当Model层的数据发生变化时，也会通知Controller层，之后会去更新View层
3. 可以看出，View层跟Model层之间的通信都是依赖Controller层的，Controller层相当于中介者，同时协调着View层跟Model层。

那么，在MVC模式下，App的组成可以分为三部分

1. Model层：负责数据的持久化存储以及读取操作
2. View层：负责视图数据的展示和交互
3. Controller层：充当中介者，负责连接model层和view层。它将数据从model层传递到view层，同时将view层的交互传递到model层从而改变模型存储的数据。

优点

1. 代码总量少。基本上，MVC大量的逻辑和视图代码都集中在ViewController层，Model层只是实现简单的数据存储，View层主要负责视图数据的展示和交互。
2. 简单易懂。MVC的设计模式可以让开发者很容易熟悉以及上手。

缺点

MVC的缺点也很明显，大量的代码都集中在了Controller层。

1. 代码过于集中。ViewController层集合了视图的交互、视图的更新、布局、Model数据的获取以及更新、网络请求等业务逻辑等大量的代码。
2. 难以进行测试。大量的代码都堆积在了ViewController层，高度耦合难以测试。
3. Model层过于简单。相比ViewController的庞大代码，Model 层只是定义几个属性在 Objective-C 的.m 实现文件中，更是几乎看不到代码。
4. 网络请求逻辑无从安放。网络层放在 Model中，网络请求一般是异步调用的，那如果网络请求的周期比Model对象的生命周期还要长，那么就会使Model层的逻辑变得很复杂，若是将网络层放在ViewController中，则耦合进一步加剧，以上缺点更会被放大。

MVP

MVP模式的提出旨在解决MVC模式下Controller层过于臃肿的问题，那么在MVP模式下，会将Controller层的处理视图交互、发起网络请求更新Model数据以及更新视图View等一部分的业务逻辑抽离出来，减轻了Controller层的负担。

MVP的示意图如下：

image.png

从图中可以看出：
MVP模式是在MVC模式上衍生出了一个Presenter层，以及更新了不同层之间的持有关系。

• View层以及Controller层持有Presenter层
• Presenter层持有Model层

每层的分工

1. View层：这里的View层是包含View以及Controller的。主要负责视图的布局以及一部分的视图交互。
2. Model层：依然是负责数据的持久化存储以及读取。
   3.Presenter层：负责接收来自View层的交互，并更新数据到Model层，当Model层数据变更时，负责通知View层更新视图。

根据不同层之间的持有关系，我们可以推断出MVP模式的工作逻辑：

1. View层和Controller层都持有presenter层，而视图交互逻辑主要在presenter层，那么内部实现应该是View层将视图交互通知到presenter层，但是本身View层创建出的视图是被addSubView进Controller层的根视图的，所以Controller层又会持有View层，那么另一种实现可以是：Controller层作为View层的代理，View层将处理视图交互的操作定义在协议里，将交互事件传递给Controller层，而Controller层本身持有presenter层，那么就调用presenter层实现的对于视图交互的方法。
2. 要注意的是，Controller层始终是核心层，它负责对于各个层主要的连接以及管理。

简单理一下用户交互的事件传递流程：
用户点击View视图 -> View视图触发交互事件 -> 交互事件传递代理Controller层 -> Controller层调用Presenter层实现好的交互操作 -> 发起网络请求更新持有的model数据 ->model层更新完毕之后通过代理或者通知到Presenter层 -> Presenter层再通过代理或通知通知到Controller层或者View层。
具体的MVP设计实例

优点

1. 相比于MVC，减轻了Controller层的负担，耦合度大大降低

缺点

view的所有交互都要传给Presenter处理，从而一旦功能增加了，View的代码和Presenter的代码都会增加，相比于MVC在ViewController一个文件里面直接解决，MVP的总代码量可能会翻倍，这样App的维护成本和文件都会增大。因此在MVC的基础上又衍生出了一种新的模式MVVM。

MVVM

MVVM模式是基于MVC模式的，在MVC的基础上分离出业务处理的逻辑到ViewModel层，即

MVVM.png MVP.png

MVVM设计模式的示意图其实跟MVP的很相似，第二张图是MVP设计模式的示意图。
可以发现

• 在View层跟View Model层之间是双向的，但这不是相互持有的关系，这是一种类似于通知的方法，当View的数据发生变化会自动通知到View Model，当View Model的数据发生变化，也会自动通知到View，所以总的来说，MVVM模式就是在MVP模式上新增了双向绑定。
• 目前主流的双向绑定方案主要有RAC以及KVO
• View/Controller 持有 View Model，View Model持有Model，那说明View Model的职责在于分担Controller层的视图交互、网络请求、更新Model模型数据等的业务逻辑。
• 尽管在MVVM模式下，没有明确指出Controller层的指责划分，但是我们仍然是将Controller层充当Manager的身份，管理各个层以及将业务逻辑分配到View Model层。

我们再来看一下MVP模式下的业务逻辑

image.png

而在MVVM模式下，P层通知V层数据发生改变就不需要定义协议或者通知了，根据KVO或则RAC实现绑定，当一方数据发生变化即会通知到另一方.

优点

相比于MVP模式，代码量大大减少。

缺点

利用RAC实现双向绑定需要引入第三方响应式框架，而且因为属性观察环环相扣，调用栈变大，Debug起来会比较痛苦。

如有错误，欢迎指出👦