Android應用架構之MVP實現

回顧上一篇文章 《Android應用架構概述》 ，我們知道，Android App 本質上抽象成兩個層次：檢視和資料。為了App在發展過程中快速的適應變化，方便維護和快速迭代，我們要將資料和檢視解耦，而在解藕方面我們的前輩們在漫長的軟體開發經驗中為我們提供了兩套流行的指導框架：MVC和MVP，其中MVP近年來在Android應用開發上逐漸流行。接著上一篇的內容，本章我將結合具體例子說清MVP解藕的實現。所以本章的思路是：以登入為業務場景，分析對比“非MVP”和MVP的實現方式。demo地址： https://github.com/liuguangli/MVPTeach

業務場景

簡單的登入場景。提交登入資訊（使用者名稱和密碼），處理登入邏輯，返回使用者資訊並儲存。

非MVP的實現

在沒有任何分層的指導思想下，我們往往或把檢視邏輯資料邏輯都耦合到Activity中來實現。

登入按鈕的響應方法：

登入檢查：

登入到伺服器：

在這裡，Activity和Http框架（android－ansyc－http）以及整改資料請求邏輯耦合了。如果以後登入邏輯變化了，那麼App所有和登入邏輯相關的頁面都會受到牽連；或者Http框架更換了，所有Activity都要受到牽連。（本demo只有一條業務場景一個Activiy體現不出影響的嚴重性，一個完整的App就能體現出來了）

儲存資料：

資料儲存的方式有很多中，也可能會隨著需求的變化而選擇不同的方式，同理，如果所有的Activiy都這樣耦合，那麼日後想要切換更合適的儲存方式將變得寸步難行。

MVP的實現

沿著《Android應用架構概述》的思路，我們先把登入這個業務場景實現的層次圖畫出來。

類圖：

LoginActivity的實現

資料請求和處理邏輯交出去了。至此，Activity變的簡單，只負責UI的變化行為，資料請求和處理邏輯的具體實現對它沒有影響。

LoginPresenter的實現

LoginPresenterImp作為LoginPresenter的實現類。它的任務和職責是：一、接受LoginActivity提交的登入指令並向LoginManager傳遞任務（真正的請求在LoginManagerImp中執行）。二、接受LoginManagerImp回撥的結果。

LoginManager的實現

LoginManager才是正真處理業務邏輯的傢伙，它和兩個模組有直接聯絡。它的職責：一、把來自UI的資料解析成網路框架層所需格式並呼叫網路框架層請求伺服器資料。二、呼叫本地資料訪問層（DAO）存取資料。三、向Presenter傳遞資料。

用好雙刃劍

任何東西都有兩面性，mvp雖然為資料檢視解耦提供了很好的指導思想，但是我門發現層次變多了，呼叫棧變多了。著就要求開發人員能夠清晰的認識業務劃分，清楚的知道MVP中，那個層次該做什麼、哪個層次不該做什麼。例如：就就面的實現，我門做一點變化：

正如圖註釋所訴，雖然在形式結構上作了MVP的設計，但因為層次職責沒化清，View層作了Mode該作的事情，並沒有達到解耦的目的。

demo: https://github.com/liuguangli/MVPTeach