iOS应用层架构的定义及CDD详解

　从2010年开始接触iOS开发到现在，折腾过不少App的架构。从MVC到MVVM，VIPER，MVP，以及最新的ReactiveCocoa都做过实战尝试，还有其他变种，诸如猿题库iOS客户端架构设计，也做过一些学习研究。这些技术概念如果不熟悉，建议每个链接都点开好好研读下，不要对你的大脑太温柔。在开始架构讨论之前，再推荐一些其他非常值得一读的文章：唐巧－被误解的 MVC 和被神化的 MVVM， Casa Taloyum iOS架构系列文章，objc.io架构系列文章。
　　1.应用层架构定义
　　其实严格来说，MVC和其他类似概念还算不上一个完整的架构。一个颇具规模的App必然会涉及到分层的设计，还有模块化、Hybrid机制、热补丁等等。MVC这种更像是个设计模式，解决的只是App分层设计当中的应用层（Applicaiton Layer）组织方式。对于一些简单App来说，可能应用层一层就完成了整个App的架构，不用担心业务膨胀对后期开发的压力。这里我介绍一种新的应用层架构方式，名之为CDD：Context Driven Design。
　　先明确下我们讨论的范畴，什么是一个App的应用层呢？现在不少App都会做一个分层的设计，一般为三层：应用层、Service层、Data Access层。每一层再通过面向接口的方式产生依赖。
　　应用层是直接和用户打交道的部分，也就是我们常常用到的UIViewController，负责数据的展示，用户交互的处理，数据的采集等等。
　　Service层位于应用层的下面，为应用层提供公共的服务接口，对应用层来说就像是一个Server，不过API调用的延迟为0ms，Service层里放哪些代码做法没有统一的规范，一般来说会包含业务数据的处理，网络接口的调用，公共系统服务API封装（比如GPS定位、相册、权限控制）等等。
　　Data Access层顾名思义是负责处理我们App的基础数据，API设计规范一般遵循CRUD。这一层位于Service层的下方，提供数据库交互所需的API。
　　这是基础部分，不同的团队具体做法又会有一些差异。比如有些把Data Access层又叫做Model层，有些把网络模块放在Service层，有些则放在Data Access层，有些把部分的业务数据放到Model里面做成胖Model，有些则坚持使用瘦Model，把业务代码放在独立的地方统一管理，等等差异不一而足。除了分层还有一些公共模块的设计，比如数据库、网络、安全、热补丁、Hybrid机制、性能监测模块、日志模块等等如何配合分层设计，这里就不一一展开了。我们今天讨论的重点在应用层。
　　首先声明下，这个CDD其实是我很久之前看Android代码脑洞出来的，刚好解决了我之前组织应用层代码的一个痛点。做过Android的朋友应该都知道，在很多类里都可以通过getContext方法获取到一个context，再通过这个context可以获取到其他系统资源。当时我第一次了解完这个context概念的时候，瞬间产生了一个这样的脑洞：
　　
　　我知道这灵光一闪的脑洞有点大，容我慢慢道来。前面提到应用层其实是在管理一堆UIViewController。拿微信做例子（我真的很喜欢拿微信举个栗子），首页4个tab，4个界面，4个controller，每个controller都有很多UI元素，点击又可以进入二级的controller，各controller可以看成一个独立的模块，有些简单，有些复杂。比如聊天界面这个controller就非常非常的复杂。