本片文章主要講的網絡層和業務層的對接方面
我們常用的將數據交給業務層的有Delegate，Notification，Block三種方式。
我們根據：
- 盡可能減跨層訪問限制耦合
- 統一回調方法，便于調試和維護
- 跟業務層對接只采用一種對接手段
- 容易追蹤，容易維護
- 不會延長對象的生命周期
- 復合在離散場景下每次回調一致的規范
選擇Delegate方式。
交付什么樣的數據給業務層
這里有兩種方式：
- 將網絡層拿到的json數據轉化為對應的對象原型（通用類型）
- 采用適配器模式，我添加DataFactory對象用于封裝數據轉化的邏輯
分析一下兩種方式的優缺點：
方式1：
- 數組內容的轉化成本較高
- 容易出現類型爆炸，提高維護成本
方式2：
- 數據會散落在各處，提高維護成本
- 對數據內部的key值得替換成本較高
這里我們把方式一和方式二結合使用：
以Factory作為輸出的終端控制器，根據自己的需求定制不同的Factory，并在Factory內部對數據進行組裝之轉化為響應的對象模型。
對以上的說明：
- Factory是一個遵循RXBaseRequestDataReformer協議的對象
- Api的原始數據由manager保管，Factory方法取manager內的數據進
行組裝，轉換并生成響應的對象模型 - 在一個view展示不同的數據的api數據的時候適宜使用Factory（因為Factory輸出標準化的對象原型）
采用Factory模式的好處：
- 處理單view對多api以及多view對多api時非常優雅，隔離轉化邏輯和主體業務邏輯
- 可以對Controller內部的代碼減負，提高靈活性，只切換Factory就能滿足不同的業務邏輯對數據的需要
- 業務邏輯和業務有了適當的隔離，當業務邏輯發生改變時改變Factory即可
選擇集約型API的調用方式還是離散型API的調用方式
- 集約型API的調用方式調用的所有的API只有一個類
- 離散型API是一個API對應一個manager，并且manager只要提供參數就可以發起請求，API的名字和著陸方式已經集成到APImanager中
- 對于網絡層的下層采用的是集約方式，對于和業務的對接層采用的是離散型的方式
采用離散化方式的優點：
- API請求的著落點消失，離散型API可以很好的處理
- 離散型API的調用方式可以給業務方提供靈活性
我們可以再底層采用集約化的方式進行數據請求，在業務方采用離散化的API來調用。
怎么進行APIManager的繼承，
由于子類可能重寫父類不允許重寫的方法，所以我們提供IOP（面向接口編程）方式來限制子類的重載。
這里是我網絡層封裝的源碼
