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