讲解Android架构之MVP,MVVM

作者:课课家教育更新于： 2017-05-03 14:05:22

　　最近有打算写一些独立的app的打算，所以对现在的Android架构与技术的选择进行了重新的思考，抛开那些乱七八糟的东西，以一个极客的态度去选择。大家可以参考一下。

     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_AndroidMVP模式简单易懂的介绍方式

　　MVC中View接受事件,并调用Controller来操作Model,同时,当Model实例的数据发生变化后，Controller再更新界面(当然View也可以直接更新Model)。

　　在传统的开发中Activity俨然既充当了Controller又充当了View的作用.既需要接受用户响应操作Model,又要更新界面.

　　这样做有一个好处就是数据的更新变得很简单,但是缺点也十分明显,Activity是非臃肿,后期不好维护.

　　MVP:

　　MVP_AndroidMVP模式简单易懂的介绍方式

　　MVP中将业务逻辑单独抽出Presenter,View层变成一个被动的东西,Presenter负责完成View层与Model层的交互.

　　View不可以直接和Model交互(MVC中允许Model和View交互),只有Presenter告知其更新，它才会去更新.

　　而且Presenter和View的交互是通过接口来完成.

　　MVVM:

　　MVVM_MVVM_Android-CleanArchitecture

　　MVVM在Android上对应databinding,MVVM最先使用在WPF中,通过ViewModel和View的映射,完成了View和Model的双向绑定.

　　View的事件直接传递到ViewModel，ViewModel去对Model进行操作并接受更新.进而反馈到View上.

　　因为ViewModel与View的耦合,MVVM有一个缺点就是View的复用问题,

　　因为去掉了Presenter,View层依然过重.

　　MVPVM:

　　MVPVM_从零开始的Android新项目3-MVPVMinAction,谁告诉你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,databinding,clean,dagger,contentprovider,rxjava等不同方式来实现相同的功能,当然我们只要掌握其精髓,触类旁通就可以

　　看官方MVP的体会

　　单独模块抽取IContract接口管理IView和Presenter接口,一目了然,而且维护也方便

　　publicinterfaceAddEditTaskContract{

　　interfaceViewextendsBaseView{

　　//...

　　}

　　interfacePresenterextendsBasePresenter{

　　//...

　　}

　　}

　　当Fragment作为View的时候,Activity负责创建IView和Presenter实例,并将二者关联起来,官方的这幅图即可说明

　　代码说明:

　　//todo-mvp$TasksActivity

　　@Override

　　protectedvoidonCreate(BundlesavedInstanceState){

　　super.onCreate(savedInstanceState);

　　setContentView(R.layout.tasks_act);

　　//...

　　TasksFragmenttasksFragment=

　　(TasksFragment)getSupportFragmentManager().findFragmentById(R.id.contentFrame);

　　//...

　　mTasksPresenter=newTasksPresenter(

　　Injection.provideTasksRepository(getApplicationContext()),tasksFragment);

　　//...

　　}

　　IPresenter由具体的Presenter实现,IView由View层(Activity/Fragment)实现,IView实现类中包含了Presenter,他们通过如下方式实现绑定.

　　publicinterfaceBaseView{

　　//View中保持对Presenter的引用。

　　voidsetPresenter(Tpresenter);

　　}

　　同时在Presenter构造时需要传入IView对象(用于更新View).

　　publicclassTasksPresenterimplementsTasksContract.Presenter{

　　privatefinalTasksRepositorymTasksRepository;

　　privatefinalTasksContract.ViewmTasksView;

　　//...

　　publicTasksPresenter(@NonNullTasksRepositorytasksRepository,@NonNullTasksContract.ViewtasksView){

　　mTasksRepository=checkNotNull(tasksRepository,"tasksRepositorycannotbenull");

　　mTasksView=checkNotNull(tasksView,"tasksViewcannotbenull!");

　　//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逻辑接口

　　publicinterfaceVu{

　　voidinflate(LayoutInflaterinflater,ViewGroupcontainer,Bundlebundle);

　　ViewgetView();

　　}

　　作为Presenter的BaseActivity,覆盖了所有生命周期方法

　　publicabstractclassBasePresenterActivityextendsActivity{

　　protectedVvu;

　　@Override

　　protectedfinalvoidonCreate(BundlesavedInstanceState){

　　super.onCreate(savedInstanceState);

　　try{

　　vu=getVuClass().newInstance();

　　vu.inflate(getLayoutInflater(),null,null);

　　setContentView(vu.getView());

　　onBindVu();

　　}catch(InstantiationExceptione){

　　e.printStackTrace();

　　}catch(IllegalAccessExceptione){

　　e.printStackTrace();

　　}

　　}

　　@Override

　　protectedfinalvoidonDestroy(){

　　onDestroyVu();

　　vu=null;

　　super.onDestroy();

　　}

　　protectedabstractClassgetVuClass();

　　protectedvoidonBindVu(){};

　　protectedvoidonDestroyVu(){};

　　}

　　举个例子:

　　具体的UI逻辑,不论Presenter变为Activity还是Fragment都不用改变.在周期方法中改变View对外的操作即可.

　　publicclassHelloVuimplementsVu{

　　Viewview;

　　TextViewhelloView;

　　@Override

　　publicvoidinit(LayoutInflaterinflater,ViewGroupcontainer){

　　view=inflater.inflate(R.layout.hello,container,false);

　　helloView=(TextView)view.findViewById(R.id.hello);

　　}

　　@Override

　　publicViewgetView(){

　　returnview;

　　}

　　publicvoidsetHelloMessage(Stringmsg){

　　helloView.setText(msg);

　　}

　　}

　　具体的Presenter

　　publicclassHelloActivityextendsBasePresenterActivity{

　　@Override

　　protectedvoidonBindVu(){

　　vu.setHelloMessage("HelloWorld!");

　　}

　　@Override

　　protectedClassgetVuClass(){

　　returnHelloVu.class;

　　}

　　}

　　MVVM:数据的动态绑定

　　官方文档:

　　https://developer.android.com/topic/libraries/data-binding/index.html

　　使用DataBinding后,我们的XML和之前是不太一样的.抄袭自官方文档

　　....

　　相应的Activity的setContentView也会变化

　　@Override

　　protectedvoidonCreate(BundlesavedInstanceState){

　　super.onCreate(savedInstanceState);

　　MainActivityBindingbinding=DataBindingUtil.setContentView(this,R.layout.main_activity);

　　Useruser=newUser("Test","User");

　　binding.setUser(user);

　　}

　　这里一个JavaBean对应一个xml布局文件,View的复用变得很困难.

　　TheMVP:MVVM和MVP的结合

　　MVC简介

　　MVC全名是ModelViewController，如图，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

　　其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。

　　Android中的MVC

　　Android中界面部分也采用了当前比较流行的MVC框架，在Android中：

　　视图层(View)

　　一般采用XML文件进行界面的描述，这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。

　　控制层(Controller)

　　Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Actiivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。

　　模型层(Model)

　　我们针对业务模型，建立的数据结构和相关的类，就可以理解为AndroidApp的Model，Model是与View无关，而与业务相关的（感谢@Xander的讲解）。对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。

　　TheMVP解决了这个问题,通过在Presenter中定义ViewModel接口,实现数据的双向绑定与MVP的结合.

　　项目地址:kymjs/TheMVP

　　核心代码:这里的IDelegate相当与上面的Vu

　　//ViewModel接口

　　publicinterfaceDataBinder{

　　/**

　　*将数据与View绑定，这样当数据改变的时候，框架就知道这个数据是和哪个View绑定在一起的，就可以自动改变ui

　　*当数据改变的时候，会回调本方法。

　　*

　　*@paramviewDelegate视图层代理

　　*@paramdata数据模型对象

　　*/

　　voidviewBindModel(TviewDelegate,Ddata);

　　}

　　Presenter:在数据改变的时候调用notifyModelChanged()更新View

　　publicabstractclassDataBindActivityextends

　　ActivityPresenter{

　　protectedDataBinderbinder;

　　publicabstractDataBindergetDataBinder();

　　publicvoidnotifyModelChanged(Ddata){

　　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进行操作.

　　其实架构性的东西在我看来没有一定的固定的写法，包括mvp和mvvm也可以根据自己的业务和理解去做不同的代码区分，像前阵子也有人提出了基于MVP与MVVM的mvvmp的架构，所有架构是死的，人是活的，记得面试听过一个大神说要跳出设计模式的圈圈，会有很多新的发现。。。共勉。

更多详细内容尽在课课家哦！