三個問題,
- 輸入
- 中間的數(shù)據(jù)轉(zhuǎn)化
3.數(shù)據(jù)的輸出
一 輸入
封裝兩三個接口,供業(yè)務(wù)層調(diào)用.
優(yōu)點(diǎn): 簡單,易用
缺點(diǎn): 可定制性低,對于復(fù)雜的API,要在調(diào)用的時候,做很多的工作. 所以網(wǎng)絡(luò)層的代碼,要下載VC或者業(yè)務(wù)層里.而且不用地方使用,要寫多次.比較混亂.每一個API對應(yīng)一個類,分布式接口
優(yōu)點(diǎn): 易定制,一次定制,復(fù)用度高
缺點(diǎn): 如果網(wǎng)絡(luò)API較多,會有很多的API類文件
總結(jié): 可以采用集中式和分布式結(jié)合的方式,抽象出上層的基類,對于定制程度高的API,基礎(chǔ)基類,完成定制. 簡單的api,使用基類即可.
二 數(shù)據(jù)的轉(zhuǎn)化.
- request .
對于header,Method,paramters,要提供定制接口,在基類中,也要提供公共方法
2.response. 提供返回值的校驗(yàn)接口,在基類中,公共校驗(yàn)方法 - 數(shù)據(jù)的剝離和轉(zhuǎn)化,如果最外層為無用數(shù)據(jù),可以做外層數(shù)據(jù)的剝離. 還有XML轉(zhuǎn)化為JSON
三: 數(shù)據(jù)的輸出
- 輸出方式
notification: 優(yōu)點(diǎn): 簡單易用,一對多
缺點(diǎn): 代碼的跨層調(diào)用,層級關(guān)系不清晰. 代碼可讀性連續(xù)性低
delegate: 一對一,層級關(guān)系清晰
代碼可讀性連續(xù)性低
block: 代碼可讀性連續(xù)性高.
缺點(diǎn): 注意造成crash
1: 輸出格式.要不要轉(zhuǎn)化為model是一個問題.
