iOS架构设计(一)- MVC

·  阅读 6498

谈起架构,是个很大很大的词,在开发行业里似乎又是个很虚很虚的词,一般情况下,我都是很少去阐述,更多的是应用到自己平时的工作跟解决问题中

人人都可以谈架构,毕竟谈起来又不需要备案,合适与否,无从可知

架构,最终是要落实到项目上,是否有定式可言

本着敬畏之心,试着展开一些,当然,一篇文章没办法谈论多宏大的项目架构跟多优秀的优化设计,只能本着从解决问题的解读阐述一些观念,重点还是在于思想

这里不在于谈论对与错,没有什么意义,但是可以相较出更好与更适合

让我们开始

文中涉及demo下载地址 github

先呈现最初阶的代码

这里我们实现了一个tableView,cell操作加减数字

image.png

image.png

image.png

image.png

image.png

这样的代码很好理解,但是,是不用思考的代码逻辑,但却违背了mvc的规范,

  • cell里可以直接操作model数据的修改

  • 视图(tableView)在viewcontroller里,跟控制粘在了一起

改为mvc设计

1.把控制器中的数据源剥离

单独构建一个datasource

image.png

image.png

viewController被改成这样

image.png

datasource 这样

image.png

cell 中的操作到数据同步逻辑断了

image.png

image.png

datasource抽离之后,目前视图是正常的

cell中直接操作model,对model的侵入过深,调整为把操作通过控制器穿出来

操作脱离cell传出时,需要indexPath依赖

image.png

如果想最小粒度保障操作与数据状态同步,cell传递出操作,响应的换回操作后的数据返回

注意:循环引用问题

但如果操作跟数据变化同步不是即时的话,如果存在异步,可能cell会被销毁,这个时候需要采用代理的方式,model更新之后,控制器需要协调reloadData

其实,这个时候,一个相对合乎MVC规范的设计就成型了

image.png

貌似还是有些些问题

2.把view从控制器抽离

如果view复杂的话,就需要把view从controller中分离,保障controller职责的清晰

image.png

现在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模式

# iOS架构设计(二)- MVP

文中涉及demo下载地址 github

分类:
iOS
标签:
分类:
iOS
标签:
收藏成功!
已添加到「」, 点击更改