iOS网络层设计感想

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，除了使用起来很是方便，功能还很是全，全方面覆盖。小伙伴们本身去学习吧。