你好，我想請教個問題杈抢，我在設計網絡層的時候用到以下如圖那種模式数尿，請問有什么弊端？謝謝惶楼。思路就是在model里面實現(xiàn)請求數(shù)據(jù)封裝數(shù)據(jù)右蹦，具體類調用時候通過block返回裝載model的數(shù)組。
original.jpg
回答：
- 沒有針對API的request做封裝鲫懒。
一個API請求的組成不是只有URL的嫩实，還包括請求的header，header中有很多元素需要應用提供窥岩，例如公共參數(shù)甲献，請求token等。
- 沒有拆分請求
我提倡的是離散型API請求颂翼，這個在文中已經論述過了晃洒。如果你不拆成離散型API請求，你就很難針對每一個請求的中途事件做切點朦乏。舉個例子：如果你的應用調用一個需要登錄用戶才能調用的API球及，而此時你的用戶token失效，你怎么處理呻疹？
- 你采用了對象化的方式去交付數(shù)據(jù)吃引。
這就導致你的業(yè)務層必須要聲明你的Model，使得你的業(yè)務層組件如果要遷移或者復用刽锤，就必須帶著你的網絡層一起復用镊尺。
- 集約型和離散型請求
你在面向業(yè)務服務時，提供的還是集約型請求并思，這個我在文章中已經論述過了庐氮。
- block回調
由于你是集約型請求，所以你不得不采用block作為回調宋彼。然而這事實上是沒有必要的弄砍，文章中已經論述得很清楚了。
你這種模式的弊端其實我在文章里面都已經詳細列舉了输涕，你如果仔細閱讀文章的話音婶，你不應該問我這個問題。至少應該問：為什么是這樣做而不是那樣做占贫？我覺得你對比文章就可以列舉出弊端來桃熄。希望你下回問點有質量的問題。
