在現(xiàn)在的app，網(wǎng)絡(luò)請求是一個很重要的部分，app中很多部分都有或多或少的網(wǎng)絡(luò)請求，所以在一個項目重構(gòu)時，我會選擇網(wǎng)絡(luò)請求框架作為我重構(gòu)的起點。在這篇文章中我所提出的架構(gòu)，并不是所謂的 最好 的網(wǎng)絡(luò)請求架構(gòu)，因為我只基于我這個app原有架構(gòu)進行改善，更多的情況下我是以app為出發(fā)點，讓這個網(wǎng)絡(luò)架構(gòu)能夠在原app的環(huán)境下給我一個完美的結(jié)果，當(dāng)然如果有更好的改進意見，我會很樂于嘗試。

　　關(guān)于網(wǎng)絡(luò)請求框架

　　一個好的網(wǎng)絡(luò)請求框架對于一個團隊來說是十分重要的。如果一個網(wǎng)絡(luò)請求框架沒有封裝好，或者是在設(shè)計上存在問題，那么在開發(fā)上會造成許多問題，就拿這段代碼作為例子：

　?。踠eaveAPI startWithCompletionBlockWith：^（BaseRequest *baseRequest， id responseObject） {

　　//check the response object

　　BOOL isSuccess = ［leaveAPI validResponseObject:responseObject］;

　　if （isSuccess） {

　　//do something.。。

　　}

　　} failure：^（BaseRequest *baseRequest） {

　　//do something.。。

　　}］;

　　上面這段代碼存在著不少的問題，比如把請求數(shù)據(jù)的判斷放到了每一個請求中、在leaveAPI的塊方法中再次調(diào)用leaveAPI、塊參數(shù)中的baseRequest并沒有實質(zhì)作用等等……針對這些問題我會一一進行修正。

　　不要讓其他人做請求數(shù)據(jù)有效與否的判斷

　　在上面的代碼中，對resposeObject是否有效的判斷被設(shè)計成了BaseRequest類中的一個方法，程序員需要在調(diào)用網(wǎng)絡(luò)請求后，再調(diào)用該方法對responseObject進行判斷，這樣的設(shè)計存在很大的弊端。

　　在實際應(yīng)用中，很多時候程序員在調(diào)用網(wǎng)絡(luò)請求后往往會忘記調(diào)用該方法對返回結(jié)果進行判斷，甚至忘記了存在這個方法，自行對responseObject進行判斷。首先這造成了大規(guī)模的代碼重復(fù)，另一方面，不同程序員自己編寫的判斷方法散落在各個請求中，假如app在日后更新過程中改變了這個判斷標準，會給修改帶來很大困難。