App的开发无外乎从网络端获取数据显示在屏幕上，数据做些缓存或者持久化，所以网络层极为重要。原来只是把AFNetwork二次封装了一下，使得调用变得很简单，并没有深层次的考虑一些问题。
前言
参考:
网络层设计方案
这篇文章提的问题也正是我平时经常纠结的，但是一直没有深入思考。文章给的解决方案和为什么这样做让人茅塞顿开。以下主要就是我的观后感。
三个问题
- 使用哪种交互模式来跟业务层做对接？
- 是否有必要将API返回的数据封装成对象然后再交付给业务层？
- 使用集约化调用方式还是离散型调用方式去调用API？
我的设计
基本上每个网络层都会涉及到这三个问题。
我原先的设计是:
//APIClient.h
@interface APIClient : AFHTTPSessionManager
+ (instancetype)sharedRequestDataClient;
/*
* 用json格式(POST)
*/
+ (void)requestDataPostMethodWithHTTPPath:(NSString *)path
parameters:(NSDictionary *)parameters
success:(RequestSuccessBlock)success
failure:(RequestFailureBlock)failure;
/*
* 用json格式(GET)
*/
+ (void)requestDataGetMethodWithHTTPPath:(NSString *)path
parameters:(NSDictionary *)parameters
success:(RequestSuccessBlock)success
failure:(RequestFailureBlock)failure;
@end
//APIManager.h(一个个具体的请求,有多少个请求就有多少个方法)
@interface APIManager : NSObject
/**
* 获取用户信息
*/
+ (void)requestUserInfoWithSuccess:(RequestSuccessBlock)success failure:(RequestFailureBlock)failure;
...
@end
@implementation APIManager
/**
* 获取用户信息
*/
+ (void)requestUserInfoWithSuccess:(RequestSuccessBlock)success
failure:(RequestFailureBlock)failure {
[APIClient requestDataGetMethodWithHTTPPath:kUserInfo parameters:nil success:success failure:failure];
}
...
@end
APIClient继承AFHTTPSessionManager，里面做了些设置，比方说统一用json,就两个方法，get,post请求。
本来还有上传下载数据两个方法，后来所有的资源文件放阿里云上，重建了个APIOSSClient类来处理。
APIManager具体处理一个个请求，有多少请求，他就有多少方法。由它来调用APIClient。
我的回答
- 数据的传递方式:Block。
- 交付什么样的数据:NSDictionary，在Block回调里把字典处理成最终需要的数据，大多数情况下是model，在model里会有数据处理。
- APIClient是集约型，很不方便，加了个APIManager，实现离散型的调用，也就是加了个离散型调用的壳。
作者的建议
- 数据的传递方式:Delegate。
- 交付什么样的数据:不作处理，添加了reformer（名字而已，叫什么都好)，用于封装数据转化的逻辑。
- 离散型的API调用方式。
感想
看了作者的思路和源码，发现作者考虑的问题也都想到了，但是处理的方式有很大的问题。
传递方式和调用方式
最早我接手项目的时候，只有APIClient，简单地做AFNetwork做了封装，属于集约型API调用方式，用block回调是正常的。
后来发现集约型API调用方式的弊端太多了，于是我加了个APIManager，规定所有的请求必须在里面加个方法，算是加了个离散调用的壳。但是最后APIManager太大了，好多方法，维护起来好累。
所以调用的方式还是离散型的好，因为是离散型的，所有Delegate比Block好。
作者一个API对应于一个APIManager，更加容易维护。好处非常多。
传递数据
对于应该传什么数据，其实我们的理想情况是希望API的数据下发之后就能够直接被View所展示。首先要说的是，这种情况非常少。另外，这种做法使得View和API联系紧密，也是我们不希望发生的。
这是作者的想法，我们也发现了这个问题，所以会单独在写个类处理，或者转成model，在model里处理，最终变成view需要的数据。如果是model，为了不让view和model耦合，又加了个category传数据。
而作者加了个reformer统一处理，并且作者强调去model化，从根源解决了转化成本高，model和view耦合等问题。
细节就不讲了，作者开源的网络层很cool，除了使用起来非常方便，功能还非常全，全方面覆盖。小伙伴们自己去学习吧。