iOS架构设计(一)- MVC
谈起架构,是个很大很大的词,在开发行业里似乎又是个很虚很虚的词,一般情况下,我都是很少去阐述,更多的是应用到自己平时的工作跟解决问题中
人人都可以谈架构,毕竟谈起来又不需要备案,合适与否,无从可知
架构,最终是要落实到项目上,是否有定式可言
本着敬畏之心,试着展开一些,当然,一篇文章没办法谈论多宏大的项目架构跟多优秀的优化设计,只能本着从解决问题的解读阐述一些观念,重点还是在于思想
这里不在于谈论对与错,没有什么意义,但是可以相较出更好与更适合
让我们开始
文中涉及demo下载地址 github
先呈现最初阶的代码
这里我们实现了一个tableView,cell操作加减数字
这样的代码很好理解,但是,是不用思考的代码逻辑,但却违背了mvc的规范,
-
cell里可以直接操作model数据的修改
-
视图(tableView)在viewcontroller里,跟控制粘在了一起
改为mvc设计
1.把控制器中的数据源剥离
单独构建一个datasource
viewController被改成这样
datasource 这样
cell 中的操作到数据同步逻辑断了
datasource抽离之后,目前视图是正常的
cell中直接操作model,对model的侵入过深,调整为把操作通过控制器穿出来
操作脱离cell传出时,需要indexPath依赖
如果想最小粒度保障操作与数据状态同步,cell传递出操作,响应的换回操作后的数据返回
注意:循环引用问题
但如果操作跟数据变化同步不是即时的话,如果存在异步,可能cell会被销毁,这个时候需要采用代理的方式,model更新之后,控制器需要协调reloadData
其实,这个时候,一个相对合乎MVC
规范的设计就成型了
貌似还是有些些问题
2.把view从控制器抽离
如果view复杂的话,就需要把view从controller中分离,保障controller职责的清晰
现在controller里代码意图更明确了,view就是一个笼统的view,controller并不关注里面的细枝末节
3.MVC是有缺陷么?人为缺陷还是设计本身呢?
开发时间久了,经常会听到这样一个说法,mvc会随着项目的复杂度,controller会变得越来越臃肿.........
我并不认同这种说法,按照这样的逻辑,不管哪种设计,项目复杂了,各种客观的主观的原因,一不小心都会使一些代码变得臃肿,我倒认为这不是MVC的缺陷
就像最后的view从controller抽离,view最终要的是需要数据源,控制器就是想办法把view需要的交付出去,而且还必须明智,就是view只需要拿,具体怎么拿到的,我就简单放到view的初始化里
....看样子说的又太轻松了,你或许心里可能会说,就是个demo,谁都知道,仅仅这样三言两语就说MVC多好,这个demo就是MVC思想如何如何
我不否认,因为我也无法把MVC的原理做到工匠一般通过一篇文章说全说透,只能尽可能尽最大能力把一些问题通过这小小代码阐述些,也欢迎有时间有精力的同学不吝指正
这里我想参考之前的一篇文章,是关于flutter的,其中有关于flutter与原生channel通信,如何精明的设计block,感兴趣的同学可以简单看下 Flutter引擎源码分析(二) - channel原生通信
4.自然而然引出另一个问题
目前代码阐述的还是简单的demo MVC说明,如果view变得更复杂呢,业务上很远的view 甚至controller 相互之间会有交集,而且view也会变得复杂得多得多,controller需要协调的控制业务也不单单是demo里那么纯粹
我觉得那是对MVC有些悲观了,MVC本身就不是罗塞塔那么生生堆成一个庞然大物,最后尾大不掉,那是因为MVC 分层分块的,简单的说就是 业务逻辑视图不断拆分拆分,每个拆分都可以作为一个MVC去设计。 我自认为目前是没有能力把这块说的很具体很透彻了,除非拿一个相当大体量的项目来拆解,显示在这篇文章里就不现实了
不过另一种设计模式 俗称的MVP,可能更利于说明上述的问题应该怎么编排
MVP模式
见(二)尽快更文
文中涉及demo下载地址 github