之前有对iOS认知中做过一次简单的分析

既然说是架构：那么这边要考虑到的是整个项目，如果是一个层次简简单单的项目，对于架构来说也没有非常大的体现意义，个人认为，架构就是能为 业务逻辑复杂的项目塑性，好的架构不仅层次清晰，开发过程也应该是愉快轻松的，不是重复的码代码！ 先从大的方面来讲： 一个App分为 网络层(Server)、数据库层(DataBase)、 应用层(Application) 三者之间的关系，如上图所展示

三者之间关系的实现：采用经典的工厂模式(ServiceFactory)来松耦合：以不同的功能模块来划分，如： 图中Sevice是提供了获取系统权限和用户逻辑相关的接口服务，随着业务的增加，项目不断的完善，Service会不断的庞大起来，一般以功能来增加不同的服务。 网络层指的是:和服务器的交互，一般封装了第三方的网络实现，一个方法一个CallBack，在Service中的某个功能下的Protocol实现； 数据库指的是：用户对数据的操作或响应服务器做出响应修改，一般底层都做了封装，暴露出行为功能的接口（增删改查等）

下面来说下一个重要的类UIResponder： 其中这张图片包含了一个重要的思想，事件追踪，它可以在我们触发的那个类里，发出事件信号，可以一直追踪到controller这一层。 这在我们写业务的时候，是个非常巧妙的事情。

接下来从小的方面Controller来解说架构： 一个App也是由多个Controller的组合而成，Controller最重要的是UI元素、逻辑和交互。如何处理好这些关系至关重要。我们现在比较流行的架构是将逻辑(presenter/businessLogic)和交互(interactor)分离出Controller，避免了Controller的臃肿，也有将View分离出去的。（架构VIPER，CDDContext等） 站在了已有的架构的基础上，做了一些修改。

如上图，PBMainController是一个主界面，里面也按Presenter、Interactor和View来划分，但是这里比正常的架构多了一个Protocol文件，这个是对应于Controller、Presenter、Interactor和View，增加这些协议类，是为了降低这4者之间的耦合度，因为在实际开发过程中，随着项目的迭代，类会越来越庞大，代码量也越来越多，如果将类的public方法或属性都写在.h中，代码的安全性就更差，团队中的其他成员可能在不清楚你的代码块的作用下，就修改了代码，这边就将类于类之间的逻辑关系都写到了Protocol中，在对应的.m里去实现。

在Controller.h中对应的Presenter、Interactor和View都是readonly属性，这样能保护它们不受外部类影响，且他们对应的baseController都是指向当前的Controller，其他子View可以通过UIResponder的特性获取到指向当前的Controller；

在上面的Main结构图可以看到：PBTestSubView是PBMainView中的一个view, testButton是PBTestSubView中的一个UIButton，那么点击testButton，跳转到另外一个界面，正常的App可能是通过两个Delegate或者NSNotification来实现。但是如果用Protocol和baseController来实现，那就是在testButton点击的时候，能之间将事件传递到指定的Controller，再获取到对应的Interactor，这样的实现是不是简单很多？

我们利用UIResponder的特性，可以在任何一个它的子...子控件里追踪到存放它的当前Controller，从而实现界面跳转。这样代码看起来是不是很简洁明了？层次也是很清楚。

总结：站在前人的基础上，修改了下架构，还是比较容易的。 这个架构的思想： 大的方面是工厂模式，Service 管理了 数据层、网络层、和应用层之间的关系。 小的方面利用UIResponder、Protocol 结合之前网络上的框架来松耦合。 架构层次很明显，主体框架代码我们可以写个脚本来生成，这样可以避免大量码代码的时间，而且也不易出错。

在gitHub上给出了一个

码云访问地址

Demo中应该能看到这个架构的整个思想，具体的数据库和网络的管理也是要分层的，它们应该在service下面的,demo中没有写了，有时间后续会完善demo。