MVC、MVP、MVVM

前言

这篇文章简单介绍MVC、MVP和MVVM三种架构，并配上一个简单的Swift demo来区分MVC和MVVM两种架构。

MVC

传统MVC

下图是传统结构MVC，可以看到这种结构是紧耦合的，不推荐使用。

苹果的MVC

如下图，这是苹果MVC架构的愿景，Controller作为View和Model的中介，这样它们就解耦了。

各层的职责如下所示：

• Model： 数据层，负责数据的处理和获取的数据接口层。
• View： 展示层(GUI)，对于 iOS 来说所有以 UI 开头的类基本都属于这层。
• Controller： 控制器层，它是 Model 和 View 之间的胶水或者说是中间人。一般来说，当用户对 View 有操作时它负责去修改相应 Model；当 Model 的值发生变化时它负责去更新对应 View。

如上图所示，M和View应该是完全隔离的，由C作为中间人来负责二者的交互，同时三者是完全独立分开的，这样可以保证M和V的可测试性和复用性。

MVC在iOS中的实现

由于Apple的规范，一个界面的呈现都需要构建一个viewcontroller，而每个viewcontroller都带有一个根view，这就导致C和V紧密耦合在一起构成了iOS里面的C层，这明显违背了MVC的初衷。实际结构如下图。

根据苹果对MVC架构规范的描述，原文戳这里，viewcontroller其实是view和controller的组合，目的就是为了提高开发效率，简化操作。但这样也会导致一个问题，就是View层的代码全堆到了VC，比如VC中构建View，View的显示逻辑处理等等。

MVC各层功能

controller层（VC）

• 生成view，然后组装view
• 响应View的事件和作为view的代理
• 调用model的数据获取接口，拿到返回数据，处理加工，渲染到view显示
• 处理view的生命周期
• 处理界面之间的跳转

model层

• 业务逻辑封装
• 提供数据接口给controller使用
• 数据持久化存储和读取
• 作为数据模型存储数据

view层

• 界面元素搭建，动画效果，数据展示，
• 接受用户操作并反馈视觉效果

关于Model层，这里有一段文章引用说明了真正的Model层实际不应该只有几个结构和属性，应该有的是数据的业务逻辑。

理解Model层：

首先要正确的理解MVC中的M是什么？他是数据模型吗？答案是NO。他的正确定义是业务模型。也就是你所有业务数据和业务实现逻辑都应该定义在M层里面，而且业务逻辑的实现和定义应该和具体的界面无关，也就是和视图以及控制之间没有任何的关系，它是可以独立存在的，您甚至可以将业务模型单独编译出一个静态库来提供给第三方或者其他系统使用。

在上面经典MVC图中也很清晰的描述了这一点： 控制负责调用模型，而模型则将处理结果发送通知给控制，控制再通知视图刷新。因此我们不能将M简单的理解为一个个干巴巴的只有属性而没有方法的数据模型。

其实这里面涉及到一个最基本的设计原则，那就是面向对象的基本设计原则：就是什么是类？类应该是一个个具有不同操作和不同属性的对象的抽象（类是属性和方法的集合）。 我想现在任何一个系统里面都没有出现过一堆只有数据而没有方法的数据模型的集合被定义为一个单独而抽象的模型层来供大家使用吧。 我们不能把一个保存数据模型的文件夹来当做一个层，这并不符合横向切分的规则。

Model层实现的正确姿势：

1. 定义的M层中的代码应该和V层和C层完全无关的，也就是M层的对象是不需要依赖任何C层和V层的对象而独立存在的。整个框架的设计最优结构是V层不依赖C层而独立存在，M层不依赖C层和V层独立存在，C层负责关联二者，V层只负责展示，M层持有数据和业务的具体实现，而C层则处理事件响应以及业务的调用以及通知界面更新。三者之间一定要明确的定义为单向依赖，而不应该出现双向依赖
2. M层要完成对业务逻辑实现的封装，一般业务逻辑最多的是涉及到客户端和服务器之间的业务交互。M层里面要完成对使用的网络协议(HTTP, TCP，其他)、和服务器之间交互的数据格式（XML, JSON,其他)、本地缓存和数据库存储（COREDATA, SQLITE,其他)等所有业务细节的封装，而且这些东西都不能暴露给C层。所有供C层调用的都是M层里面一个个业务类所提供的成员方法来实现。也就是说C层是不需要知道也不应该知道和客户端和服务器通信所使用的任何协议，以及数据报文格式，以及存储方面的内容。这样的好处是客户端和服务器之间的通信协议，数据格式，以及本地存储的变更都不会影响任何的应用整体框架，因为提供给C层的接口不变，只需要升级和更新M层的代码就可以了。比如说我们想将网络请求库从ASI换成AFN就只要在M层变化就可以了，整个C层和V层的代码不变。

MVP

结构如下图。

MVC中没有对业务逻辑和业务展示进行区分，MVP就是针对这一点进行的优化，它将业务逻辑和业务展示做了一层隔离。M和V功能不变, 原来的C现在只负责布局, 而所有的业务逻辑全都转移到了P层。P层处理完了业务逻辑，如果要更改view的显示，那么可以通过回调来实现，这样可以减轻耦合，MVP从视图层中分离了行为（事件响应）和状态（属性，用于数据展示），它创建了一个视图的抽象，也就是presenter层，而视图就是P层的『渲染』结果。P层中包含所有的视图渲染需要的动态信息，包括视图的内容（text、color）、组件是否启用（enable），除此之外还会将一些方法暴露给视图用于某些事件的响应。

MVP通信过程

1. 当视图接收到来自用户的事件时，会将事件转交给 Presenter 进行处理；
2. 被动的视图实现presenter的代理，当需要更新视图时 Presenter回调代理来更新视图的内容，这样让presenter专注于业务逻辑，view专注于显示逻辑
3. Presenter 负责对模型进行操作和更新，在需要时取出其中存储的信息
4. 当模型层改变时，可以将改变的信息发送给观察者 Presenter

MVVM

MVVM由三个部分组成，也就是 Model、View 和 ViewModel；其中视图模型（ViewModel）其实就是 MVP 模式中的P，在 MVVM 中叫做VM，架构图如下。

MVVM相对于MVP做的改进就是对VM/P和view做了双向的数据和命令绑定，利用Binder机制使得Model和View可以状态同步。

具体实例看MVC与MVP/MVVM的实现对比

可以看到项目中，MVVM比MVC多了一个ViewModel层，这是两者的不同，我们先来看看相同的Model和ViewController，两者除了命名不同其他的都相同，所以以下只展示一种。

Model

ViewController

fetchData部分写的内容是模拟网络请求数据，代码如下图。

fetchData

接下来让我们看到MVC中的View层

MVCView

可以看到在这里对业务的显示和业务的逻辑处理都放在了View层。

我们反观MVVM架构中，加入了一个ViewModel，它对业务逻辑部分抽象出了一个类，代码如下。

最后我们在View中，只用处理业务展示部分即可，代码如下。

以上就是MVC、MVP、MVVM的简要介绍。