這篇文章不光是我對自己知識的一個總結，更多的是想通過這篇文章認識到自己的不足。希望大家能給點建議。大家相互學習！
網絡層在一個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有哪些。只需要點擊對象模型就能清晰了解對象結構并以點的獲取屬性就可以加以使用。
總結：
關于網絡層搭建基本都是圍繞著幾個問題來的。問題解決完了，一個簡潔版的網絡層也就出來了。為了使開發人員能不看文檔也能使用你的框架，暴露出去的接口盡量做到簡潔易懂。
