淺談Android架構之MVP,MVVM


概述

MVP(Model-View-Presenter)是傳統MVC(Model-View-Controller)在Android開發上的一種變種、進化模式。主要用來隔離UI、UI邏輯和業務邏輯、數據,創建松散耦合並可重用的對象。

我們知道View層是容易變化且多種多樣的,業務邏輯也是多種多樣的,與傳統的MVC相比,P充當了C的作用.
Model存儲數據,View表示Model的表現,Presenter協調兩者之間的通信.

而后在MVP基礎上也出現了一些變種,如MVVM,MVPVM等,相比較MVP而言,MVVM使數據綁定變得更加簡單.MVPVM在MVVM中加入引入Presenter層

MVC,MVP,MVVM,MVPVM圖解

這里感謝源博客和圖片提供者.

MVC:

MVC_Android MVP模式 簡單易懂的介紹方式

MVC中View接受事件,並調用Controller來操作Model,同時,當Model實例的數據發生變化后,Controller再更新界面(當然View也可以直接更新Model)。

在傳統的開發中Activity儼然既充當了Controller又充當了View的作用.既需要接受用戶響應操作Model,又要更新界面.
這樣做有一個好處就是數據的更新變得很簡單,但是缺點也十分明顯,Activity是非臃腫,后期不好維護.

MVP:

MVP_Android MVP模式 簡單易懂的介紹方式

MVP中將業務邏輯單獨抽出Presenter,View層變成一個被動的東西,Presenter負責完成View層與Model層的交互.
View 不可以直接和Model交互(MVC中允許Model和View交互),只有Presenter告知其更新,它才會去更新.
而且Presenter和View的交互是通過接口來完成.

MVVM:

MVVM_MVVM_Android-CleanArchitecture

MVVM在Android上對應data binding,MVVM最先使用在WPF中,通過ViewModel和View的映射,完成了View和Model的雙向綁定.
View的事件直接傳遞到ViewModel,ViewModel去對Model進行操作並接受更新.進而反饋到View上.
因為ViewModel與View的耦合,MVVM有一個缺點就是View的復用問題,
因為去掉了Presenter,View層依然過重.

MVPVM:

MVPVM_從零開始的Android新項目3 - MVPVM in Action, 誰告訴你MVP和MVVM是互斥的

MVPVM是MVP和MVVM的演化版本,降低了ViewModel與View的耦合,View只需要實現ViewModel的觀察者接口實現更新.ViewModel不再對Model直接進行操作,而是交給了Presenter.Presenter操作Model並反饋到ViewModel上
Model,View,ViewModel之間通過Presenter聯系了起來.

MVP實踐

Google官方android-architecture 無疑是學習MVP最佳資料,官方項目展示了通過不同方式來實現MVP,其中展示了通過basic,loaders,data binding,clean,dagger,content provider,rxjava等不同方式來實現相同的功能,當然我們只要掌握其精髓,觸類旁通就可以

看官方MVP的體會

  • 單獨模塊抽取IContract接口管理IViewPresenter接口,一目了然,而且維護也方便
public interface AddEditTaskContract {

    interface View extends BaseView<Presenter> {
//...
    }

    interface Presenter extends BasePresenter {
//...
    }
}
  • 當Fragment作為View的時候,Activity負責創建IViewPresenter實例,並將二者關聯起來,官方的這幅圖即可說明

fragment_mvp

代碼說明:

//todo-mvp$TasksActivity
@Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.tasks_act);
       // ...
       TasksFragment tasksFragment =
               (TasksFragment) getSupportFragmentManager().findFragmentById(R.id.contentFrame);
       //...
       mTasksPresenter = new TasksPresenter(
               Injection.provideTasksRepository(getApplicationContext()), tasksFragment);
       //...
   }
  • IPresenter由具體的Presenter實現,IView由View層(Activity/Fragment)實現,IView實現類中包含了Presenter,他們通過如下方式實現綁定.
public interface BaseView<T> {
      // View中保持對Presenter的引用。
      void setPresenter(T presenter);
}
  • 同時在Presenter構造時需要傳入IView對象(用於更新View).
public class TasksPresenter implements TasksContract.Presenter {
    private final TasksRepository mTasksRepository;
    private final TasksContract.View mTasksView;
//...
    public TasksPresenter(@NonNull TasksRepository tasksRepository, @NonNull TasksContract.View tasksView) {
        mTasksRepository = checkNotNull(tasksRepository, "tasksRepository cannot be null");
        mTasksView = checkNotNull(tasksView, "tasksView cannot be null!");
//setPresenter
        mTasksView.setPresenter(this);
    }
  • Model不僅僅是JavaBean,而且擁有操作數據的業務邏輯(獲取、存儲、更新),同時Model也可以將業務抽成接口,這樣就可以隨意拓展數據源

MVP變種

MVP架構的好處就不多說了,但是使用Activity/Fragment作為View層有如下問題,
參考一種在android中實現MVP模式的新思路

  • 當內存不足,Activity被回收后,這使得狀態的保存和恢復成為問題,因為涉及到了Model操作.

  • 生命周期的控制問題也很麻煩,需要在Presenter中寫一大堆和生命周期相關的接口規范

  • Activity中包含了很多系統服務,邏輯操作方便

使用Activity/Fragment作為Presenter

Activity/Fragment中的系統服務和業務邏輯緊密相關.理想的狀態是View不涉及到邏輯操作.

Activity/Fragment作為Presenter,需要將其UI邏輯抽取到一個單獨的類中來管理.

UI邏輯接口

public interface Vu {
    void inflate(LayoutInflater inflater, ViewGroup container, Bundle bundle);
    View getView();
}

作為Presenter的BaseActivity,覆蓋了所有生命周期方法

public abstract class BasePresenterActivity<V extends Vu> extends Activity {

    protected V vu;

    @Override
    protected final void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        try {
            vu = getVuClass().newInstance();
            vu.inflate(getLayoutInflater(), null,null);
            setContentView(vu.getView());
            onBindVu();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }

    @Override
    protected final void onDestroy() {
        onDestroyVu();
        vu = null;
        super.onDestroy();
    }

    protected abstract Class<V> getVuClass();

    protected void onBindVu(){};

    protected void onDestroyVu() {};

}

舉個例子:

具體的UI邏輯,不論Presenter變為Activity還是Fragment都不用改變.在周期方法中改變View對外的操作即可.

public class HelloVu implements Vu {

View view;
TextView helloView;

@Override
public void init(LayoutInflater inflater, ViewGroup container) {
    view = inflater.inflate(R.layout.hello, container, false);
    helloView = (TextView) view.findViewById(R.id.hello);
}

@Override
public View getView() {
    return view;
}

public void setHelloMessage(String msg){
    helloView.setText(msg);
}

}

具體的Presenter

public class HelloActivity extends BasePresenterActivity {
@Override
protected void onBindVu() {
    vu.setHelloMessage("Hello World!");
}

@Override
protected Class<MainVu> getVuClass() {
    return HelloVu.class;
}

}

MVVM:數據的動態綁定

官方文檔:
https://developer.android.com/topic/libraries/data-binding/index.html
使用Data Binding后,我們的xml和之前是不太一樣的.抄襲自官方文檔

<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data>
        <variable name="user" type="com.example.User"/>
    </data>
    <LinearLayout>
    ....
    </LinearLayout>
</layout>

相應的Activity的setContentView也會變化

@Override
protected void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   MainActivityBinding binding = DataBindingUtil.setContentView(this, R.layout.main_activity);
   User user = new User("Test", "User");
   binding.setUser(user);
}

這里一個JavaBean對應一個xml布局文件,View的復用變得很困難.

TheMVP:MVVM和MVP的結合

TheMVP解決了這個問題,通過在Presenter中定義ViewModel接口,實現數據的雙向綁定與MVP的結合.
項目地址: kymjs/TheMVP

核心代碼:這里的IDelegate相當與上面的Vu

//ViewModel接口
public interface DataBinder<T extends IDelegate, D extends IModel> {
    /**
     * 將數據與View綁定,這樣當數據改變的時候,框架就知道這個數據是和哪個View綁定在一起的,就可以自動改變ui
     * 當數據改變的時候,會回調本方法。
     *
     * @param viewDelegate 視圖層代理
     * @param data         數據模型對象
     */
    void viewBindModel(T viewDelegate, D data);
}

Presenter:在數據改變的時候調用notifyModelChanged()更新View

public abstract class DataBindActivity<T extends IDelegate> extends
        ActivityPresenter<T> {
    protected DataBinder binder;

    public abstract DataBinder getDataBinder();

    public <D extends IModel> void notifyModelChanged(D data) {
        binder.viewBindModel(viewDelegate, data);
    }
}

MVPVM:View復用與瘦身

在MVPVM作者的介紹中.

  • Model層,和MVP中的Model是類似的.即PO或者DO
  • View層,依然是由Activity/Fragment來擔當,不同的是需要實現ViewModel的觀察者接口,來實現View的動態更新
  • Presenter層,如上圖所示,Presenter作為核心,連接着M,V,VM
  • VM層,和MVVM中的VM是類似的,只是為了讓VM可以重用.不再和特定的View綁定,而且不再直接對Model進行操作.

詳見:從零開始的Android新項目3 - MVPVM in Action, 誰告訴你MVP和MVVM是互斥的

參考:
一種在android中實現MVP模式的新思路
ANDROID MVP模式 簡單易懂的介紹方式
MVVM_Android-CleanArchitecture
從零開始的Android新項目3 - MVPVM in Action, 誰告訴你MVP和MVVM是互斥的
用MVP架構開發Android應用


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM