你好，我想請教個問題，我在設計網絡層的時候用到以下如圖那種模式，請問有什么弊端？謝謝。思路就是在model里面實現請求數據封裝數據，具體類調用時候通過block返回裝載model的數組。
original.jpg
回答：
- 沒有針對API的request做封裝。
一個API請求的組成不是只有URL的，還包括請求的header，header中有很多元素需要應用提供，例如公共參數，請求token等。
- 沒有拆分請求
我提倡的是離散型API請求，這個在文中已經論述過了。如果你不拆成離散型API請求，你就很難針對每一個請求的中途事件做切點。舉個例子：如果你的應用調用一個需要登錄用戶才能調用的API，而此時你的用戶token失效，你怎么處理？
- 你采用了對象化的方式去交付數據。
這就導致你的業務層必須要聲明你的Model，使得你的業務層組件如果要遷移或者復用，就必須帶著你的網絡層一起復用。
- 集約型和離散型請求
你在面向業務服務時，提供的還是集約型請求，這個我在文章中已經論述過了。
- block回調
由于你是集約型請求，所以你不得不采用block作為回調。然而這事實上是沒有必要的，文章中已經論述得很清楚了。
你這種模式的弊端其實我在文章里面都已經詳細列舉了，你如果仔細閱讀文章的話，你不應該問我這個問題。至少應該問：為什么是這樣做而不是那樣做？我覺得你對比文章就可以列舉出弊端來。希望你下回問點有質量的問題。
