概述

• 定義
  MVP 其實是 MVC 的一種演進版本，它更簡單，將 MVC 中的 Controller 改為了 Presenter，View 通過接口與 Presenter 進行交互，降低耦合，方便進行單元測試。

  View：負(fù)責(zé)繪制 UI 元素、與用戶進行交互(Activity、View、Fragment 都可以做為 View 層)；
  Model：對數(shù)據(jù)的操作、對網(wǎng)絡(luò)等的操作，和業(yè)務(wù)相關(guān)的邏輯處理；
  Presenter：作為 View 與 Model 交互的中間紐帶，處理與用戶交互的邏輯?？梢园?Presenter理解為一個中間層的角色，它接受 Model 層的數(shù)據(jù)，并且處理之后傳遞給 View 層，還需要處理 View 層的用戶交互等操作。

• 作用
  1、將Model與View徹底分離。
  2、解決MVC中Activity職責(zé)過多，代碼臃腫的問題

• 三者關(guān)系
  

  image.png

MVP案例

此實例基于MVC的實例，改造為MVP模式。與MVC不同的是，一般Activty會當(dāng)作View層來處理

• Model層
  跟MVC不同的地方在于Model不會跟View發(fā)生交互，只會跟Presenter交互，實現(xiàn)了View和Model的完全分離。

data class UserModel(var userName:String){

    fun login(result: Int, listener: ModelCallBack){
        if (result == 1){
            listener.onSuccess("${userName}登錄成功")
        }else{
            listener.onFailed("${userName}登錄失敗")
        }
    }

    //回調(diào)接口 根據(jù)是否成功返回數(shù)據(jù)
    interface ModelCallBack{
        fun onSuccess(msg:String)
        fun onFailed(msg:String)
    }
}

• View層
  在MVP中Activity充當(dāng)View層角色，并持有Presenter對象的引用。
  創(chuàng)建IView接口，由Activity（即View層）實現(xiàn)方法，并暴露給Presenter調(diào)用，用于更新View。

interface IView {
    fun updateUI(msg:String)
}

Activity類：

class MainActivity : AppCompatActivity(),IView{
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val userPresenter = UserPresenter(this)
        //點擊事件  模擬向服務(wù)器請求登錄
        loginBtn.setOnClickListener{
            userPresenter.login()
        }
    }
    
    //實現(xiàn)更新界面的方法 暴露給Present調(diào)用
    override fun updateUI(msg:String) {
        textView.text = msg
    }
}

• Presenter層
  Present作為中間層，負(fù)責(zé)業(yè)務(wù)邏輯處理。
  創(chuàng)建IPresenter接口，由Present層實現(xiàn)，暴露給View層調(diào)用

interface IPresenter{
    fun login()
}

Presenter類

class UserPresenter : UserModel.ModelCallBack,IPresenter{
    lateinit var userModel:UserModel
    lateinit var iView:IView
    constructor(iView: IView){
        this.iView = iView
        userModel = UserModel("用戶${(0..9).random()}")
    }
    override fun onSuccess(msg: String) {
        iView.updateUI(msg)
    }

    override fun onFailed(msg: String) {
        iView.updateUI(msg)
    }

    override fun login() {
        userModel.login((0..1).random(),this)
    }
}

運行結(jié)果

MVP關(guān)鍵點

• View 不再負(fù)責(zé)同步的邏輯，而是由 Presenter 負(fù)責(zé)。Presenter 中既有業(yè)務(wù)邏輯也有同步邏輯。

• View 需要提供操作界面的接口給 Presenter 進行調(diào)用。（關(guān)鍵）

• 與MVC的不同

  對比在 MVC 中，Controller 是不能操作 View 的，View 也沒有提供相應(yīng)的接口；而在 MVP
  當(dāng)中，Presenter 可以操作 View，View 需要提供一組對界面操作的接口給 Presenter 進行調(diào)
  用；Model 仍然通過事件廣播自己的變更，但由 Presenter 監(jiān)聽而不是 View。

MVP的優(yōu)缺點

• 優(yōu)點

• 便于測試。Presenter 對 View 是通過接口進行，在對 Presenter 進行不依賴 UI 環(huán)境的單元測試的時候?？梢酝ㄟ^ Mock 一個 View 對象，這個對象只需要實現(xiàn)了View 的接口即可。然后依賴注入到 Presenter中，單元測試的時候就可以完整的測試 Presenter 業(yè)務(wù)邏輯的正確性。

• View 可以進行組件化。在 MVP 當(dāng)中，View 不依賴 Model。這樣就可以讓 View 從特定的業(yè)務(wù)場景中脫離出來，可以說 View 可以做到對業(yè)務(wù)邏輯完全無知。它只需要提供一系列接口提供給上層操作。這樣就可以做高度可復(fù)用的 View 組件。

• 缺點

• 維護成本相對較高。Presenter 中除了業(yè)務(wù)邏輯以外，還有大量的 View->Model，Model->View 的手動同步邏輯，造成Presenter 比較笨重，維護起來會比較困難。

• 系統(tǒng)內(nèi)存不足時，系統(tǒng)會回收Activity。一般我們都是用OnSaveInstanceState()去保存狀態(tài)，用OnRestoreInstanceState()去恢復(fù)狀態(tài)。但是在我們的MVP中，View層是不應(yīng)該去直接操作Model的，所以這樣做不合理，同時也增大了M與V的耦合。解決辦法是不要將Activity作為View層，可以把Activity當(dāng)Presenter來處理。具體實現(xiàn)這里就不分析了，有興趣的可以研究一下。

• UI改變的話，比如TextView 替換 EditText，可能導(dǎo)致Presente的一些更新UI的接口也跟著需要更改，存在一定的耦合。