从MVC基础上稍微演化一下

image.png

与上篇文章MVC有些许的不一样，首先原来的controller弱化，由presenter来驱动，其实就是代理的驱动角色，现在的viewController其实就是原来view的角色了

还记得上篇文章数据源怎么来的，viewController get到的，主要交代的是MVC布局关系，并没有涉及网络

如果加上网络部分，上文中构建好的MVC模式轻易就会被搞乱，因为基础的架构设计部分约束性不强，不自律的人也很容慢穿透这个MVC设计，慢慢就丧失了它的框架职责

可以把 iOS架构设计（一）- MVC 中的ViewController核心代码在MVP模式下一样在ViewController补充完整代码，操作之后你些许会发现别扭，如果有这样的感觉，那就相信这种感觉，带着这种感觉，一步步践行MVP的演化

正文开始前，这里就是让大家感受下这个小小的区别，接下来再复杂

带着感受，MVP再次调整

你会发现上面的调整与 MVC 大同小异，感觉很像，那没关系，接下来，就彻底清空上一步的mvp初始铺垫，再次重新开始

这不是在浪费你的时间，前面的操作也是刻意的，这样做让大家心里能够装一些想当然的东西，然后打破它，再构建，过了很长时间以后，如果再考虑架构设计，你脑子里可能就会摒弃掉固有的东西，这样才会深刻起来

context是为了不管在项目代码中什么位置，都能轻松获取到依赖

image.png

这种写法很怪，像是多此一举，不过要注意下当中的weak修饰

image.png

viewController 只会保留一些基本的关联桥接职能

image.png

presenter interactor view 不仅仅是mvp思想传达，重要的是，要从代码构建类上，让开发者更容易的get到这个信息

更有甚者，构建MVP这些基础代码可以通过执行脚本来自动生成，这样的话一个项目里，设计思想才会潜移默化的移植到潜意识里的规范手册里

毕竟代码还是靠程序猿去实现的，每个人都能清楚的意会这个设计模式，并写出风格一样的代码，那对于项目团队而言，是有很多好处的，效率肯定是没得说，而且协作之间的耦合也会变得准确，在没有必要费心思的关键结点处就不需要花费太多的时间精力

我理解的架构不就是服务于开发组么维护有合适的规范可依职责也可通过代码变得很明晰这些全都可以通过这样的一个架构轻松落实，就跟合同一样，清清楚楚

image.png

这就是效果

注意前两行代码顺序

image.png

调试代码 github

presenter逻辑

image.png

presenter红框部分就是基于代理来驱动的

可能你阅读之后又个感觉，代码云里雾里的，但代码量却不多，这样弄值得吗

非常值得！且耐心往后看

image.png

这是出现了一个新的概念，adapter，俗称适配器，如果看过了文章（一），会看到上半部分的逻辑有点像MVC里controller里的block回调

这里我简单做个解释，说一下这样抽象的思想：

MVP是presenter基于代理驱动的，所以MVC中的controller就沦为配置层，可以理解为初始化配置的操作
view的数据渲染交给了适配器，preseter自会驱动适配器
对view自身来讲，adapter也可以尝试去按照数据源的概念去理解
按照稳重的MVP构想，执行项目的话就可以拷贝代码，按照相应的格式规则去编辑代码文件类，框架设计就好了，写代码会变得很轻松大可以自己去下载代码在自己的项目里尝试一下

adapter同样需要在context里追加注册