这篇文章不光是我对自己知识的一个总结，更多的是想通过这篇文章认识到自己的不足。希望大家能给点建议。大家相互学习！
网络层在一个App中也是一个不可缺少的部分，好的网络层不光能提升开发效率还要能提升用户体验。另外，苹果对网络请求部分已经做了很好的封装，业界的AFNetworking也被广泛使用。
在网络层搭建过程中碰到的难点和问题这里先提出来。
主要会讲这些方面：
1.使用哪种交互模式来跟业务层做对接？
2.使用集约化调用方式还是离散型调用方式去调用API？
3.是否有必要将API返回的数据封装成对象然后再交付给业务层？
1.使用哪种交互模式来跟业务层做对接？
我这里是以Delegate为主 Notification为辅来跟业务层做对接的。
初期公司是以block作为主要交互模式。遇到的结果如下：
1.1.block很难追踪，难以维护
在调试的时候经常会单步追踪到某一个地方之后，发现尼玛这里有个block，如果想知道这个block里面都做了些什么事情，这时候就比较蛋疼了。
1.2.回调方法不统一，不便于调试和维护
在同一个Controller里 因为使用block发起请求，响应的着陆点不一样调试和维护起来不方便。在跟业务层对接的部分只采用一种对接手段（在我这儿就是只采用delegate这一个手段）限制灵活性，以此来交换应用的可维护性
1.3.block会延长相关对象的生命周期
在网络回调中使用block，是block导致对象生命周期被延长的其中一个场合，当ViewController从window中卸下时，如果尚有请求带着block在外面飞，然后block里面引用了ViewController（这种场合非常常见），那么ViewController是不能被及时回收的，即便你已经取消了请求，那也还是必须得等到请求着陆之后才能被回收。然而使用delegate就不会有这样的问题，delegate是弱引用，哪怕请求仍然在外面飞，，ViewController还是能够及时被回收的，回收之后指针自动被置为了nil，无伤大雅。
为了解决这些问题和统一回调方法，便于调试和维护。所以我们选择了delegate为主要设计模式。至于为什么没有选Notification为主要设计模式？是因为Notification的影响面不可控制，只要存在实例就存在被影响的可能。这也会导致谁都不能保证相关处理代码就在唯一的那个地方，进而带来维护灾难。 但是在某些层面上(比如：网络切换)需要多个APIManage处理一些问题。所以选择Notification为辅助设计模式。
2.使用集约化调用方式还是离散型调用方式去调用API？
集约型API调用其实就是所有API的调用只有一个类，然后这个类接收API名字，API参数，以及回调着陆点（可以是target-action，或者block，或者delegate等各种模式的着陆点）作为参数。然后执行类似startRequest这样的方法，它就会去根据这些参数起飞去调用API了，然后获得API数据之后再根据指定的着陆点去着陆。
集约型API调用方式：[APIRequeststartRequestWithApiName:@"itemList.v1"params:paramssuccess:@selector(success:)fail:@selector(fail:)target:self];
离散型API调用是这样的，一个API对应于一个APIManager，然后这个APIManager只需要提供参数就能起飞，API名字、着陆方式都已经集成入APIManager中。
离散型API调用方式：@property(nonatomic,strong)ItemListAPIManager*itemListAPIManager;// getter-(ItemListAPIManager*)itemListAPIManager{if(_itemListAPIManager==nil){_itemListAPIManager=[[ItemListAPIManageralloc]init];_itemListAPIManager.delegate=self;}return_itemListAPIManager;}// 使用的时候就这么写：[self.itemListAPIManagerloadDataWithParams:params];
这里我更倾向于离散型API调用方式。原因如下：
原因1：当前请求正在外面飞着的时候，根据不同的业务需求存在两种不同的请求起飞策略：一个是取消新发起的请求，等待外面飞着的请求着陆。另一个是取消外面飞着的请求，让新发起的请求起飞。集约化的API调用方式如果要满足这样的需求，那么每次要调用的时候都要多写一部分判断和取消的代码，手段就做不到很干净。
前者的业务场景举个例子就是刷新页面的请求，刷新详情，刷新列表等。后者的业务场景举个例子是列表多维度筛选，比如你先筛选了商品类型，然后筛选了价格区间。当然，后者的情况不一定每次筛选都要调用API，我们先假设这种筛选每次都必须要通过调用API才能获得数据。
如果是离散型的API调用，在编写不同的APIManager时候就可以针对不同的API设置不同的起飞策略，在实际使用的时候，就可以不必关心起飞策略了，因为APIMananger里面已经写好了。
原因2：当API请求的着陆点消失时，离散型的API调用方式能够更加透明地处理这种情况。
当一个页面的请求正在天上飞的时候，用户等了好久不耐烦了，小手点了个back，然后ViewController被pop被回收。此时请求的着陆点就没了。这是很危险的情况，着陆点要是没了，就很容易crash的。一般来说处理这个情况都是在dealloc的时候取消当前页面所有的请求。如果是集约型的API调用，这个代码就要写到ViewController的dealloc里面，但如果是离散型的API调用，这个代码写到APIManager里面就可以了，然后随着ViewController的回收进程，APIManager也会被跟着回收，这部分代码就得到了调用的机会。这样业务方在使用的时候就可以不必关心着陆点消失的情况了，从而更加关注业务。
综上： 上部分使用离散型设计（发起请求部分），下部分使用集约型设计（回调部分）。
3.是否有必要将API返回的数据封装成对象然后再交付给业务层？
对于网络层而言，统一的请求回调方式和参数有利于提升应用的可维护性。对api返回数据封装成对象或者采用NSDictionary加Const字符串key来表征都是可行的。
这里我更倾向使用对象封装返回数据。
原因：在使用过程中通过对象返回的数据使用起来更加便利。没必要去找NSDictionary key有哪些。只需要点击对象模型就能清晰了解对象结构并以点的获取属性就可以加以使用。
总结：
关于网络层搭建基本都是围绕着几个问题来的。问题解决完了，一个简洁版的网络层也就出来了。为了使开发人员能不看文档也能使用你的框架，暴露出去的接口尽量做到简洁易懂。
