在项目开启阶段,其中一个很重要的环节就是选架构。 那么面对目前已知的这么多架构模式我们该怎么选择呢?这确实是个很让人头疼的问题!  
下面我就在这里梳理一下目前常见的一些架构模式。 先逐个对它们的分析,然后在从中找到它们的规律,之后就可以以不变应万变,不会再被这些虚头巴脑的名词所迷惑。  
本篇文章主要从两个维度进行分析: 一、任务分配方式 二、逻辑分层方式   先看一下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架构。
前面的层级表示逻辑分层方式 后面的形式表示任务分配方式   对于上面讲的五种任务分配方式,因为是已经被人熟知,所有被大工程所采用。   但是目前有个疑惑
如果有时候一个业务模块很负责时,会不断的讲业务分拆。会产生很多种目录与文件。 如果模块内视图控制器跳转逻辑负责时,会引入中介者模式进行统一管理跳转。
这时,模块内的任务分配文件相对于这五种架构模式,显得有点四不像了。 这时就会疑惑,我这到底用的是什么架构模式啊?  
通过上面五种架构责任划分的介绍,我们可以知道 无论是什么架构模式,它们的区别是:任务的分配方式不同罢了。
虽然我们在任务分配后的文件和目录四不像,但是可以满足我们的业务需求和功能扩展,这就够了。 不要被形式上所限制。   那么什么是好的架构模式呢?  
个人认为比较好的架构模式为:三层MVC架构 任务分配方法是以MVC任务分配方案为基础,按照一定的原则进行个性化分配。 采用如下分配原则:
1.保留当前角色的主要功能,拆分次要功能。 2.弱业务功能放到Model中,尽量不要放到Controller里去。
3.拆分出去的业务功能尽量封装成可复用组件、对象或协议。 4.控制好拆分粒度,调用接口少参或无参。  
这样不管形式如何变化,只有架构逻辑分层在,同时满足业务需要和功能扩展就是好架构。    

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信