iOS 架构（起手式）

以前有对iOS认知中作过一次简单的分析 http://www.javashuo.com/article/p-sprspyls-dz.html

既然说是架构：那么这边要考虑到的是整个项目，若是是一个层次简简单单的项目，对于架构来讲也没有很是大的体现意义，我的认为，架构就是能为 业务逻辑复杂的项目塑性，好的架构不只层次清晰，开发过程也应该是愉快轻松的，不是重复的码代码！ 先从大的方面来说： 一个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

码云访问地址Demo

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