iOS之网络层的设计

本片文章主要讲的网络层和业务层的对接方面

我们常用的将数据交给业务层的有Delegate，Notification，Block三种方式。

我们根据：

1. 尽可能减跨层访问限制耦合
2. 统一回调方法，便于调试和维护
3. 跟业务层对接只采用一种对接手段
4. 容易追踪，容易维护
5. 不会延长对象的生命周期
6. 复合在离散场景下每次回调一致的规范

选择Delegate方式。

交付什么样的数据给业务层

这里有两种方式：

1. 将网络层拿到的json数据转化为对应的对象原型（通用类型）
2. 采用适配器模式，我添加DataFactory对象用于封装数据转化的逻辑

分析一下两种方式的优缺点：
方式1：

1. 数组内容的转化成本较高
2. 容易出现类型爆炸，提高维护成本

方式2：

1. 数据会散落在各处，提高维护成本
2. 对数据内部的key值得替换成本较高

这里我们把方式一和方式二结合使用：
以Factory作为输出的终端控制器，根据自己的需求定制不同的Factory，并在Factory内部对数据进行组装之转化为响应的对象模型。

对以上的说明：

1. Factory是一个遵循RXBaseRequestDataReformer协议的对象
2. Api的原始数据由manager保管，Factory方法取manager内的数据进
   行组装，转换并生成响应的对象模型
3. 在一个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（面向接口编程）方式来限制子类的重载。
这里是我网络层封装的源码