android mvp設計模式

什麼是MVP

MVP，全稱 Model-View-Presenter。要說MVP那就不得不說一說它的前輩——MVC（Model-View-Controller，模型-視圖-控制器）。

• View：對應於佈局文件
• Model：業務邏輯和實體模型
• Controllor：對應於Activity

細細的想一想這個View對應於佈局文件，其實能作的事情特別少，實際上關於該佈局文件中的數據綁定的操做，事件處理的代碼都在Activity中，形成了Activity既像View又像Controller。

而當將架構改成MVP之後，Presenter的出現，將Actvity視爲View層，Presenter負責完成View層與Model層的交互，其實就是activity裏邊只作和UI相關的操做，即更新UI的功能，具體何時更新，更新的數據，則是由presenter和model來決定，presenter決定何時更新並將model層的數據傳送到activity。如今是這樣的：

• View 對應於Activity，負責View的繪製以及與用戶交互
• Model 依然是業務邏輯和實體模型
• Presenter 負責完成View於Model間的交互

這樣的轉變是從並不標準的MVC到MVP的一個轉變，減小了Activity的職責，簡化了Activity中的代碼，將複雜的邏輯代碼提取到了Presenter中進行處理。與之對應的好處就是，耦合度更低，更方便的進行測試。借用兩張圖，表明上述的轉變：

轉變爲：

MVP與MVC的區別

最明顯的區別就是，MVC中是容許Model和View進行交互的，而MVP中很明顯，Model與View之間的交互由Presenter完成。以下圖所示：

爲何須要MVP

• 一、儘可能簡單

大部分的安卓應用只使用View-Model結構，程序員如今更多的是和複雜的View打交道而不是解決業務邏輯。當你在應用中只使用Model-View時，到最後，你會發現「全部的事物都被鏈接到一塊兒」。

而使用MVP則會把複雜的任務分紅細小的任務，而且很容易解決。越小的東西，bug越少，越容易debug，更好測試。在MVP模式下的View層將會變得簡單，因此即使是他請求數據的時候也不須要回調函數。View邏輯變成十分直接。

• 2：後臺任務

當你編寫一個Actviity、Fragment、自定義View的時候，你會把全部的和後臺任務相關的方法寫在一個靜態類或者外部類中。這樣，你的Task再也不和Activity聯繫在一塊兒，這既不會致使內存泄露，也不依賴於Activity的重建。

MVP的優缺點

優勢：

1. 下降耦合度，實現了Model和View真正的徹底分離，能夠修改View而不影響Modle
2. 模塊職責劃分明顯，層次清晰
3. 隱藏數據
4. Presenter能夠複用，一個Presenter能夠用於多個View，而不須要更改Presenter的邏輯（固然是在View的改動不影響業務邏輯的前提下）
5. 利於測試驅動開發。之前的Android開發是難以進行單元測試的（雖然不少Android開發者都沒有寫過測試用例，可是隨着項目變得愈來愈複雜，沒有測試是很難保證軟件質量的；並且近幾年來Android上的測試框架已經有了長足的發展——開始寫測試用例吧），在使用MVP的項目中Presenter對View是經過接口進行，在對Presenter進行不依賴UI環境的單元測試的時候。能夠經過Mock一個View對象，這個對象只須要實現了View的接口便可。而後依賴注入到Presenter中，單元測試的時候就能夠完整的測試Presenter應用邏輯的正確性。
6. View能夠進行組件化。在MVP當中，View不依賴Model。這樣就可讓View從特定的業務場景中脫離出來，能夠說View能夠作到對業務徹底無知。它只須要提供一系列接口提供給上層操做。這樣就能夠作到高度可複用的View組件。
7. 代碼靈活性

缺點：

1. Presenter中除了應用邏輯之外，還有大量的View->Model，Model->View的手動同步邏輯，形成Presenter比較笨重，維護起來會比較困難。
2. 因爲對視圖的渲染放在了Presenter中，因此視圖和Presenter的交互會過於頻繁。
3. 若是Presenter過多地渲染了視圖，每每會使得它與特定的視圖的聯繫過於緊密。一旦視圖須要變動，那麼Presenter也須要變動了。
4. 額外的代碼複雜度及學習成本。

demo以下：

目錄：

具體每一個類的代碼：

public interface IContract {
    interface IPresenter {
        void getData();
    }
    interface IView {
        void updateUI(String data);
    }
}

public class MainActivity extends AppCompatActivity implements IContract.IView{

    IContract.IPresenter iPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        iPresenter = new MyPresenter(this);

    }

    @Override
    public void updateUI(String data) {
        TextView textView = findViewById(R.id.show_data);
        textView.setText(data);
    }
}

　　

public class MyPresenter implements IContract.IPresenter {
    IContract.IView iView;

    public MyPresenter(IContract.IView iv){
        this.iView = iv;
    }

    @Override
    public void getData() {
        MyModel myModel = new MyModel();
        String s = myModel.getData();
    }
}

public class MyModel {
    public String getData(){
        return "MVP";
    }
}

　　

總結

在MVP模式裏一般包含4個要素：

• View :負責繪製UI元素、與用戶進行交互(在Android中體現爲Activity);
• View interface :須要View實現的接口，View經過View interface與Presenter進行交互，下降耦合，方便進行單元測試;
• Model :負責存儲、檢索、操縱數據(有時也實現一個Model interface用來下降耦合);
• Presenter :做爲View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。