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，除了使用起來很是方便，功能還很是全，全方面覆蓋。小夥伴們本身去學習吧。