iOS架构设计（一）- MVC

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

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

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

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

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

让我们开始

文中涉及demo下载地址 github

先呈现最初阶的代码

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

vc

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

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