App的開發無外乎從網路端獲取數據顯示在屏幕上，數據做些緩存或者持久化，所以網路層極為重要。原來只是把AFNetwork二次封裝了一下，使得調用變得很簡單，並沒有深層次的考慮一些問題。 前言 參考: "網路層設計方案" 這篇文章提的問題也正是我平時經常糾結的，但是一直沒有深入思考。文章給的解決方案和 ...
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，除了使用起來非常方便，功能還非常全，全方面覆蓋。小伙伴們自己去學習吧。
