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

人人都能够谈架构，究竟谈起来又不需求存案，合适与否，无从可知

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

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

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

让我们开始

文中涉及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模式

# iOS架构规划（二）- MVP

文中涉及demo下载地址 github