MVP模式的經典封裝

人之所以能，是相信能。

說到MVP，大家應該都不陌生了，由於其高度解等等優點，越來越多的項目使用這個設計模式。然而，優點雖在，缺點也不少，其中一個就是類多了很多，而且V與P直接要項目通信，那麼P就得持有V得實例，但如果活動掛掉了，如果沒有對V進行釋放，還有導致內存溢出得問題，而且，那麼多的介面函數，看得到人眼花繚亂，也使得很多人在使用這個模式的時候望而尚步。

回歸正題，最近在進行代碼重構，決定採用MVP模式進行開發。如果我們不進行封裝，單純地簡單使用MVP來開發，這要就會出現如上的問題，介面和類多而且重複。和別人協同開發也存在問題。那麼對MVP模式進行封裝就顯得很重要了。當然，一千個人中有一千個哈姆雷特，這裡提供一下我的思路，供大家參考。

什麼是MVP模式

MVP模式相當於在MVC模式中又加了一個Presenter用於處理模型和邏輯，將View和Model完全獨立開，在android開發中的體現就是activity僅用於顯示界面和交互，activity不參與模型結構和邏輯。

使用MVP模式會使得代碼多出一些介面但是使得代碼邏輯更加清晰，尤其是在處理複雜界面和邏輯時，我們可以對同一個activity將每一個業務都抽離成一個Presenter，這樣代碼既清晰邏輯明確又方便我們擴展。當然如果我們的業務邏輯本身就比較簡單的話使用MVP模式就顯得，沒那麼必要。所以我們不需要為了用它而用它，具體的還是要要業務需要。

其實，簡而言之：view就是UI，model就是數據處理，而persenter則是他們的紐帶。

使用MVP的結構再對比下MVC

MVP模式還是存在一些不足之處的，最大的不足就是類的快速增多，但相對於MVC的臃腫、MVP的高度解耦來說，類的增多可能就洒洒水啦

~

封裝思路

上圖介紹：

Contract：契約類，一個功能模塊中View介面、Model介面和請求數據回調統一在對應模塊的Contract中定義，便於管理。

ViewInterface： view層介面，定義了view中的UI操作

ModelInterface： model層介面，定義了model負責的數據操作方法，如請求介面，操作資料庫等

CallbackInterface： model層操作數據完成後的回調

BasePersenter： Persenter父類，主要是對相關view的獲取，銷毀等操作

View： view層實現類，主要就是Activity或Fragment，負責UI展示和事件響應

Model： model層實現類，就是依據業務，請求對應介面或資料庫，並將結果返給回調CallBack

Persenter： persenter層類，負責業務邏輯處理，view將響應傳給persenter，persenter負責調用model，並將結果返回給view供其展示

框架封裝1、Presenter的封裝

先來觀察下這個base類：

先設置一泛型T，T為與presenter相關的view。BasePresenter中持有一個view的軟引用。

在關聯方法中將view對象傳入，並存入軟引用中，創建獲取、取消關聯和判斷方法。

至於使用軟引用，是為了防止所持的view都銷毀了，但presenter一直持有，導致內存泄漏。

2、view的封裝

view的封裝，主要是BaseActivity和BaseFragment的封裝。

2.1、BaseActivity

BaseActivity設置兩個泛型——V和P，明顯地，分別代表對應的View和Presenter。

其持有一個BasePresenter，在onCreated方法中，使用createPresenter方法返回對應的BasePresenter的子類，我們就可以使用了。

這裡注意一下view和presenter的處理：在onCreated中創建Presenter對象，但其內部的view軟引用還是空；在onResume中關聯view，此時presenter已經持有view的軟引用；當然，還需要在onDestroy中取消關聯。

至於其他的封裝就不再介紹了，相信大家肯定還有更優的封裝方法。

2.2 BaseFragment

BaseFragment與BaseA類似就不再累贅。

3、Contract契約類

契約，顧名思義，規範定義，定義功能和模板。

在契約類中定義View的介面，Model的介面。因為Model將數據返給Presenter是使用回調方式，所以還需要再契約類中定義對應的回調。

具體看示例吧。

實戰

這裡我們以登錄功能模塊為例：

1、契約類

這裡定義了登錄頁面的view介面、model介面和對應的回調。

在view中，只定義與UI展示的相關方法，如檢查賬號密碼格式成功（失敗）、登錄成功（失敗）等。

model負責數據請求，所以在介面中只定義了登錄的方法。

回調定義了登錄成功還是失敗的方法。

2、Model實現類

創建Model實現類，重寫其登錄方法既可，將登錄介面交給回調。

3、Presenter

LoginPresenter集成BasePresenter，傳入LoginView最為泛型T。

內部持有Model實現類對象。

創建兩個方法，一個是檢查格式，一個是登錄。兩個方法就是業務的處理。

如登錄方法，登錄返回後，在回調中得到數據，也可以再進行一些邏輯判斷，將結果交給view的對應的方法。

注意這裡使用getView()方法就可以，因為在父類中getView方法直接返回的對應的view實例。

4、View

這裡的LoginActivity就是登錄功能模塊的view，其集成BaseActivity，傳入view和presenter泛型。

實現LoginView介面，重寫介面定義好的UI方法。

在createPresenter方法中創建LoginPresenter對象並返回。這樣，就可以使用mPresenter直接操作邏輯了。

再看下整個功能模塊的事件流和數據流

大致就是這樣了，有不足的地方大家多提意見。^_^

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！