应用层架构之CDD

本文集是iOS架构方面的备忘（我的博客全是备忘，能不能来点原创Orz...）

本文是我非常喜欢的iOSer MrPeak的博客的理解和备忘，原文地址：iOS应用层架构之CDD

这里是demo的地址 CDD的demo

1.应用层架构定义：

一个颇具规模的app必然会涉及到分层的设计，还有模块化，hybrid机制，热补丁等等。

现在不少app都会做一个分层的设计，一般为三层：应用层，service层，data access层。每一层再通过面向接口的方式产生依赖

• 应用层是直接和用户打交道的。
• service层在应用层下面，为应用层提供公共的服务接口。一般来说会包含业务数据的处理，网络接口的调用，公共系统服务api封装（比如gps定位，相册，权限控制）等等
• data access层顾名思义是负责处理我们app的基础数据，有些把data access层又叫做model层。

2. data flow

首先：架构的作用，就是拆分代码 ，以低耦合的方式分散业务复杂度。data flow就是数据在你的app里流动的路线。拆分代码后，数据会经历很多拆分后的模块。data flow是架构优劣的测量标准，好的架构一定有清晰的data flow。

3. CDD架构详解

以低耦合的方式分散业务复杂度后，分散的各个类文件之间怎么交互，怎么合体。MVC，MVVM，MVP等等都是在解决这个问题。下边是MrPeak的解决方案 Context Dirven Design（context驱动架构）：

cdd结构图

cdd要达成的目标：

• view被分解成若干子View， 各自管理。
• 业务代码放在BusinessObj
• model变化使用dataHandler处理
• viewController只放生命周期相关。
• 子view的展示通过context获取，通过kvo绑定。

4. CDD的实现细节

CDDContext就是之前提到的核心类context，还包含CDDDataHandler， CDDBusinessObject基类的定义。

NSObject+CDD给每个NSObject对象添加一个CDDContext指针。

UIView+CDD则通过swizzling的方式给每个UIView自动添加CDD。

CDDMutableArray实现对Array的观察者模型。

5. 需要完善的细节：

• 对更多集合类的支持： 入Dictionary
• BusinessObject 可能业务膨胀
• 因为通过hack view的 didAddSubview方法给每个view 赋值了context。可以做个限制。

6. 我的看法：

• 1. 作者使用 BusinessObj 和 dataHandle还有树结构的子View来解耦MVC，避免臃肿的controller。
• 2. 作者通过用runtime来给每个View添加Context，这样，View，businessObj，dataHandle和controller都持有Context来进行通讯。
• 3. context直接持有dataHandle和businessObj。即view通过context拿到数据，view的变化和输入通过context给businessObj。
• 4. 作者通过KVO，delegate绑定来将model的变化通知view。

//通过context来通讯