前言
计算机学科领域的任何问题都可以通过增加一个间接的中间层来解决.(重点)
这句话几乎概括了计算机系统技术软件体系的结构要点, 整个体系从上到下都是按照严格的层级结构设计的. 所以不管是什么设计模式, 只要它适用于你的项目, 适合你当前的整个情况, 它就是好的.
没有最好的设计模式, 是有适合自己的模式
老生常谈的MVC, MVP, MVVM, 今天不想说每个设计是什么样的. 只是解析一下不同设计的想法和方式
MVC
作为最经典, 普及的设计模式MVC, 使用起来是非常简易切易于上手的.
PS: 事件分发机制, 其实用户产生事件的时候, 也是V响应告诉C去拿数据, 所以1流程可以当做V发起的.
所以MVC的核心就是视图和数据的分离.
优
- 部署快
- 上手快
- 可重用性高
劣
- VC臃肿
- Model过于轻量
- 可测试性差
- 还有一点就是VC中的网络逻辑, 好像在这里不管写在哪个模块似乎都可以...
优劣都有很多我也写不完, 但是MVC仍然是经典中的经典, 不管是什么模式, 都是根据中间层概念附加在MVC之上实现的.
MVP(Presenter)
通过协议和P类, 去隔绝Model层.
- p类要做的事情就是绑定V(一般弱引用), 绑定M, 提供外部接口网络请求.
- V调用网络请求, P内部调用M触发请求, M将数据回调给P, P回调V的协议.
- V拿到数据, 刷新UI. 整个流程大概就是这样.
按照开头一句话, 就是一个中间层.
- 一般情况下, 会对V和VC在进行拆分
- 在
View接受到用户事件,View会绑定P(是遵循P的协议的一个对象), 然后调用P的协议 - 触发
P事件, 然后回调给V, 刷新. 大概是下面这么一种形态:
等于之前是以VC为媒介, 现在是以P为媒介, 通过协议实现.
网上很多资料有些是View也是直接绑定到P层面, P去处理主要的任务.
比如
UITableView, 可以把DataScoure代理单独拉出来, 使得UITableView的dataScoure等于自己设置的继承于UITableViewDataScoure协议的类, 该类实现了协议的方法, 暴露数据接口. 这样TableView的代理就分离出来了一个具体类, VC里面代码就会简洁很多.可以优化的小细节很多, 具体看技术选型和方案了, 小东西都是大框架定了之后慢慢优化的.
优
- 等于是借用中间层概念, 使用一个
P层分摊了C层面的任务. - 易于测试, 可复用性强.
- 概念会相对清晰.
劣
- 代码, 文件会比MVC模式多
- 理解上难度稍稍比
MVC高一点
MVVM
网上的一些方案, 大致的意思就是说, ViewModel虽然叫法不一样, 实质上是把ViewModel当做Model使用, 并且绑定了Model. 大致就是MVC的框架, 把M 扩展成VM这么一个东西.
- 这样做的实际意义并不是很大, 只是做了个
VC和Model的中间层, 而且也没有MVP好.
所以在iOS里面MVVM的架构是基于RAC实现的:
没有RAC的MVVM是下图这样:
有了RAC函数响应式框架, 整个MVVM就显得有意义了. 下图:
看看这个图和MVP的图, 感觉好像一模一样...
优势劣势就不说了, RAC我也没怎么接触过, 不好误解大家.
总结
只是想说下面这一句
如果不是打算找工作, 我可能不太想写这种东西, 只是为了记录一下增加记忆, 记性不是很好.
我的swift你在忍忍, 找完工作就宠幸你.
计算机学科领域的任何问题都可以通过增加一个间接的中间层来解决.
