本片文章主要讲的网络层和业务层的对接方面
我们常用的将数据交给业务层的有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（面向接口编程）方式来限制子类的重载。
这里是我网络层封装的源码
