MVC、MVCS、MVVM、MVP、VIPER等这么多架构模式哪个好呢？

在项目开启阶段，其中一个很重要的环节就是选架构。

那么面对目前已知的这么多架构模式咱们该怎么选择呢？这确实是个很让人头疼的问题！

下面我就在这里梳理一下目前常见的一些架构模式。

先逐个对它们的分析，而后在从中找到它们的规律，以后就能够以不变应万变，不会再被这些虚头巴脑的名词所迷惑。

本篇文章主要从两个维度进行分析：

1、任务分配方式

2、逻辑分层方式

先看一下MVC、MVCS、MVVM、MVP、VIPER架构模式的任务分配方式

MVC

MVC是最经典的架构模式，它出现的时间很是早，也是最被人所熟知的。

MVC架构的任务分工为：

M-model：

1.数据结构表示

2.读取本地数据

3.写数据到本地

4.处理弱业务

C-Controller：

1.处理主要业务逻辑

2.处理交互事件

3.协调V-M数据流

V-View：

1.展现数据

2.处理非逻辑交互事件。

根据上面描述，总之一句话归纳：

M：管理数据， C：处理数据， V：展现数据。

MVCS

看名字就感受这个MVCS架构模式是从MVC中分化出来的，事实上也确实如此。

S为Store的简称，意思为“存储，保存”。

下面来看一下多出一个S后，它们的分工有什么变化呢？

S-Store：

1.负责数据的存储，数据本地持久化。

M-Model：

1.数据结构表示

2.读取本地数据

3.处理弱业务

C-Controller：

1.处理主要业务逻辑

2.处理交互事件

3.协调V-M数据流

V-View：

1.展现数据

2.处理非逻辑交互事件。

从上面的分工可知C，V同MVC架构是彻底同样的，只有M的数据存储任务被分离了出来。即：S分担了M的数据管理任务，那么M和S其实都是数据管理的逻辑范畴了。

根据上面描述，总之一句话归纳：

（M+S）：管理数据， C：处理数据， V：展现数据。

MVVM

MVVM为了解决前端的响应式编程而生，因为前端网页混合了HTML、CSS和JavaScript，并且页面众多，代码的组织和维护难度复杂，因此经过ViewModel实现View和Model的双向绑定。

可是移动端不是前端，从业务处理逻辑上讲，移动端要比前端处理的逻辑更多，你问我有啥依据。你能够把手机的网断掉，进入带有离线功能的APP，一套业务走下来，没啥问题。可是用浏览器打开呢，纵然添加了缓存，也是不能将一套业务走完的。

因此说，移动端要比前端处理的逻辑多！

看到MVVM你会有疑问，为啥没有C了，是否是用这个MVVM就不须要C了呢？若是你是移动端的同窗，我给你讲是有C的。

MVVM架构在移动端的完整叫法是：M-V-C-VM。

MVVM架构的任务分工为：

M-model：

1.数据结构表示

2.读取本地数据

3.写数据到本地

4.处理弱业务

C-Controller：

1.处理交互事件

2.协调V-M数据流

VM-ViewModel:

1.处理主要业务逻辑

V-View：

1.展现数据

2.处理非逻辑交互事件。

从上面的分工可知，VM分担了C中的数据加工任务，将业务处理放到了ViewModel中，其余的M,V同MVC架构彻底同样。

总之一句话归纳：

M：管理数据， （C+VM）：处理数据， V：展现数据。

MVP

MVP从MVC衍生而来，从名称上看只是将C换成了P。其余都同样。而事实上呢？

它们也确实这样，P承担了C的任务而已。

区别是：它们两个的数据流向不同

 

MVC的数据流向图

 

MVP的数据流向图

对比一下，就能够同样看出了。

MVC框架中，V的数据从Model中拿

MVP框架中，V的数据从Presenter中拿。

MVP架构的任务分工为：

M-model：

1.数据结构表示

2.读取本地数据

3.写数据到本地

4.处理弱业务

P-Presenter：

1.处理主要业务逻辑

2.处理交互事件

3.协调V，M数据流，从M读取数据，将数据经过接口供V调用。

V-View：

1.展现数据

2.处理非逻辑交互事件。

根据上面描述，总之一句话归纳：

M：管理数据， P：处理数据， V：展现数据。

VIPER

VIPER是责任粒度划分比较细的一个架构模式，是按照“责任单一原则”的标志来走的，每一个类所承担的任务更简单。

VIPER架构的任务分工为：

E-Entity：

1.数据结构表示

2.读取本地数据

3.写数据到本地

I-Interactor：

1.处理主要业务逻辑

P-Presenter:

1.处理弱业务

2.处理交互事件

R-Routing:

1.处理视图的展现顺序逻辑或者说是控制器的跳转控制

V-View：

1.展现数据

2.处理非逻辑交互事件。

根据上面描述，可粗略的归纳为：

E：管理数据， （I+P+R）：处理数据， V：展现数据。

架构从逻辑分层上讲，常见有两种：

三层架构：展现层，业务层，数据层。

四层架构：展现层，业务层，网络层，本地数据层。

架构从任务分配上讲，常见有五种：

MVC、MVCS、MVVM、MVP、VIPER

而一般在工程中，这两个维度的思想是同时存在的。

好比：三层MVC架构，四层MVC架构。

前面的层级表示逻辑分层方式

后面的形式表示任务分配方式

对于上面讲的五种任务分配方式，由于是已经被人熟知，全部被大工程所采用。

可是目前有个疑惑

若是有时候一个业务模块很负责时，会不断的讲业务分拆。会产生不少种目录与文件。

若是模块内视图控制器跳转逻辑负责时，会引入中介者模式进行统一管理跳转。

这时，模块内的任务分配文件相对于这五种架构模式，显得有点四不像了。

这时就会疑惑，我这到底用的是什么架构模式啊？

经过上面五种架构责任划分的介绍，咱们能够知道

不管是什么架构模式，它们的区别是：任务的分配方式不一样罢了。

虽然咱们在任务分配后的文件和目录四不像，可是能够知足咱们的业务需求和功能扩展，这就够了。

不要被形式上所限制。

想免费学习Java工程化、分布式架构、高并发、高性能、深刻浅出、微服务架构、Spring，MyBatis，Netty源码分析等技术的朋友，能够加群：479499375，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们，欢迎进群一块儿深刻交流学习。

那么什么是好的架构模式呢？

我的认为比较好的架构模式为：三层MVC架构

任务分配方法是以MVC任务分配方案为基础，按照必定的原则进行个性化分配。

采用以下分配原则：

1.保留当前角色的主要功能，拆分次要功能。

2.弱业务功能放到Model中，尽可能不要放到Controller里去。

3.拆分出去的业务功能尽可能封装成可复用组件、对象或协议。

4.控制好拆分粒度，调用接口少参或无参。

这样无论形式如何变化，只有架构逻辑分层在，同时知足业务须要和功能扩展就是好架构。