MVP模式从入门到精通

来源:互联网 发布:网络舞曲 编辑:程序博客网 时间:2024/05/17 22:02

首先MVP 是从经典的MVC架构演变而来,那我们是不是要先说下何为MVC模式?

系统C/S(Client/Server)三层架构模型:

1)视图层(View):一般采用XML文件对应用的界面进行描述,使用的时候可以直接引入,极为方便,可以的大大缩短开发时间,也可以使用JavaScript+HTML等的方式作为View层,当然这里需要进行Java和JavaScript之间的通信,幸运的是,Android提供了非常方便的通信实现。业务逻辑层(BLL):它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。

2)控制层(Controller):Android的控制层的重任通常落在了众多的Acitvity的肩上,这句话也就暗含了不要在Acitivity中写代码,要通过Activity交割Model业务逻辑层处理。

3)模型层(Model):对数据库的操作、以及其他和数据有关的的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。

   三层结构架构三层间的交互及作用如下图所示:


传统的MVC模式是很不错,我们也很熟悉,毕竟用了这么多年了。(突然想到之前去一家公司面试他问个HelloWord的Android项目是不是MVC,我说不是,他说回答错误,阿西吧!)

在Android项目上你会发现Activity的责任太重,什么东西都要放在Activity中,最终导致了Activity太过臃肿。虽然能抽的都抽出来了,但是会发现代码还是很多,试想下上千行代码还没有注释,能不晕?即使是自己写的,过些日子去看也有些晕晕的吧?

尤其代码敲完,一个月后需求又改了,从600、700行代码中找到要修改的地方也是要一点功夫的。

为了给Activity减轻压力,这时候MVP出现了!

MVP有什么好处,为什么要用MVP呢?

网上搜下一大堆MVP的各种好处,本人总结下主要有以下几点:

  • 代码解耦
  • 结构清晰
  • 可复用
  • 扩展性高
  • 方便进行单元测试

MVP中View并不直接使用Model,它们之间的通信是通过Presenter
(MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会从直接Model中读取数据而不是通过 Controller。

在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过接口进行交互,从而使得在变更View时候可以保持Presenter的不变,可以多次复用。
在MVP里,应用程序的逻辑主要在Presenter来实现,其中的View是很薄的一层,只应该有简单的Set/Get的方法,用户输入和设置界面显示的内容,除此就不应该有更多的内容,绝不容许直接访问Model。
MVP主要解决就是把逻辑层抽出来成P层,要是遇到需求逻辑上的更改就可以只需要修改P层了或者遇到逻辑上的大改我们可以直接重写一个P也可以,很多开发人员把所有的东西都写在了Activity/Fragment里面这样一来遇到频繁改需求或者逻辑越来越复杂的时候,Activity /Fragment里面就会出现过多的混杂逻辑导致出错,所以MVP模式对于APP来对控制逻辑和UI的解耦来说是一个不错的选择。
上面说逻辑是在Presenter中处理的,假设这是一个登陆界面,如要输入账号密码,那么对账号密码的是否为空判断以及正则表达式判断等也要放在Presenter中,毕竟这些都是逻辑。
然后判断都成功的话(下面的操作都是在Presenter中进行的),先调用view层的方法,让ProgressDialog显示出来,然后调用model层的网络请求,结果的话在presenter中回调。在回调里面分别做ProgressDialog消失的处理,然后成功的话调用view层的方法,进入主界面。失败的话调用view层的方法,提示失败Toast之类的。
这就是最简单的一个流程了。

MVP是什么?怎么实现?
下图是本人Demo中的代码,就一个页面而已,然而一个页面竟然有这么多的类,11个,我勒个去,吓死宝宝了,这么多的类,说实话一个类就能解决了。不慌,下面让我们仔细分析为什么这么多类

首先介绍下每个类是干嘛的:
BuyBooActivity是我们的Activity
  • BaseActivity是Activity的基类

  • BasePresenter是Presenter的基类

  • BuyBookBean是我们的bean,也就是传说中的实体类,几个成员变量,自动生成一堆get、set方法的那个类
  • IBuyBookView也就是BuyBooActivity的接口
  • BuyBookPresenter也就是这个Actvity的Presenter
  • IBuyBookPresenter是BuyBookPresenter的接口

  • BuyBookModel是这个Activity的数据层
  • IBuyBookModel是BuyBookModel的接口

  • BuyBookAdapter是BuyBooActivity里面ListView的适配器
  • ValueCallBack,是一个通用的回调接口

  • 这里接口都以I开头,每个model,presenter,还有Activity的view,都对应着一个接口,有些人可能会问了,干嘛写接口,一下多了这么多类,看的都懵逼了(比如以前有一个同事,他一直说项目用MVP,但是他不知道什么是MVP,直接把数据层写在了P中,估计是他以为bean才是model吧。我也不跟他说,毕竟人家工资比较高。说道这里突然想起了他以前的MVVM模式,第一个M是bean,他说这是model,第二个M以及一个V他说这是viewmodel,结果放的是所有的网络请求,最后一个V他放的是Aciivty和Fragment了。好了笑话说到这里,继续我们的主题


    为什么写接口?
    问这个问题的童鞋应该去复习设计模式的六大基本原则了,我们要控制项目而不是项目控制我们,我们要进行的是面向接口的编程,用抽象(或者接口)搭建框架,用实现扩展细节。当然接口也不能滥用,都要看具体情况,这里本人是按照最高标准来写的。


    Google官方MVP示例项目是把上面的IBuyBookPresenter以及IBuyBookView这2个接口放到了IBuyBookContract这个协议类中,实际上是一样的,这就看个人喜好了,各有各的优缺点。比如把本栗子的代码改成有协议类的这种就如下代码所示,看到了吧,其实是一样的。

    1. public interface IBuyBookContract  
    2. {  
    3.     interface IBuyBookView  
    4.     {  
    5.         void showToast(String msg);  
    6.   
    7.         void refreshAdapter();  
    8.   
    9.         void onEmpty();  
    10.     }  
    11.   
    12.     interface IBuyBookPresenter  
    13.     {  
    14.   
    15.         List<BuyBookBean> getAdapterData();  
    16.     }  


    M(Model)
    数据层,和MVC中的M一样,用来放数据的处理(比如网络请求,缓存等)。

    V(View)
    负责UI具体实现展现。比如Presenter派发过来一个动作是showDialog显示进度命令,那么我们这个View就负责实现具体UI。

    P(Presenter)
    负责处理业务逻辑代码,处理Model数据,然后将处理完的数据分发到View层。

    下面开始贴代码讲解


    先来讲View IBuyBookView

    这里主要是包含了Activity的一系列关于UI操作,然后用我们的Activity是实现,这样Presenter就可以调用了。


    1. public interface IBuyBookView {  
    2.     /** 
    3.      * 提示toast 
    4.      */  
    5.     void showToast(String msg);  
    6.   
    7.     /** 
    8.      * 刷新adapter 
    9.      */  
    10.     void refreshAdapter();  
    11.   
    12.     void onEmpty();  
    接下来讲Model IBuyBookModel
    BuyBookModel

    主要是写了几个方法供BuyBookModel去实现

    [java] view plain copy
    print?
    1. public interface IBuyBookModel {  
    2.     /** 
    3.      * 获取模拟数据 
    4.      */  
    5.     void getTestData(ValueCallBack<List<BuyBookBean>> callBack);  
    6.   
    7.   
    8.     /** 
    9.      * 返回本地adapter数据 
    10.      * @return 
    11.      */  
    12.     List<BuyBookBean> getAdapterData();  
    13. }  


    这里实现了IBuyBookModel,然后模拟了下网络请求,用随机来模拟请求成功与失败,所以如果有童鞋下载Demo发现进去怎么空白一片,那么请退出来多近几次,本人曾连续5次进去都是空白的,这运气也太背了吧。


    1. public class BuyBookModel implements IBuyBookModel {  
    2.     private List<BuyBookBean> listData;  
    3.   
    4.   
    5.     public BuyBookModel() {  
    6.         this.listData = new ArrayList<>();  
    7.     }  
    8.   
    9.     @Override  
    10.     public void getTestData(final ValueCallBack<List<BuyBookBean>> callBack) {  
    11.         new Handler().postDelayed(new Runnable() {  
    12.             @Override  
    13.             public void run() {  
    14.                 List<BuyBookBean> list = new ArrayList<>();  
    15.                 list.add(new BuyBookBean("赵云"1"09-27 09:11"));  
    16.                 list.add(new BuyBookBean("赵云、隔壁老王、小王、典韦、貂蝉、林芳、曹操、刘备、关羽、黄忠、张飞、诸葛孔明"10"09-27 09:11"));  
    17.                 list.add(new BuyBookBean("黄忠、孙权、大乔"50"09-27 09:11"));  
    18.                 list.add(new BuyBookBean("大乔、小乔、貂蝉、孙尚香"300"09-27 09:11"));  
    19.   
    20.                 Random rd = new Random();  
    21.                 int N = rd.nextInt(10);  
    22.                 if (N > 5) {  
    23.                     callBack.onSuccess(list);  
    24.                 } else {  
    25.                     callBack.onFail("拒绝请求");  
    26.                 }  
    27.             }  
    28.         }, 1000);  
    29.     }  
    30.   
    31.   
    32.     @Override  
    33.     public List<BuyBookBean> getAdapterData() {  
    34.         return listData;  
    35.     }  
    36. }  


    这里贴上楼上那个回调接口,这里用了泛型,为什么呢?为了多多复用。


    1. public interface ValueCallBack<T> {  
    2.     void onSuccess(T t);  
    3.   
    4.     void onFail(String code);  
    5. }  


    接下来讲Presenter BasePresenter IBuyBookPresenterBuyBookPresenter

    这个是所有Presenter的基类,里面有个initData()方法,基本每个Presenter都要处理网络请求吧,所以我就弄了这么一个基类,至于为什么是抽象的而不是接口,这是因为抽象方便点吧,如果我们往抽象类中添加新的方法(该方法不是抽象的),可以给他提供默认的实现,而且不要修改现有的代码,但是如果是接口的话,就要修改现有的代码了。指不定我们以后要往这里加什么呢。

    这里为什么用了个泛型?为了让人一看这个Presenter就知道这对应着哪个Activity,实际上这可以不加的,但是我觉得加上去更好。便于后来人也便于自己以后再来修改这个类。

    1. public abstract class BasePresenter<T extends BaseActivity> {  
    2.   
    3.     abstract void initData();  
    4. }  

    这里主要写了个方法,以供BuyBookPresenter实现


    1. public interface IBuyBookPresenter {  
    2.   
    3.     List<BuyBookBean> getAdapterData();  
    4. }  

    这里首先实现现了IBuyBookPresenter继承了BasePresenter,然后重写一些方法。这里的构造方法是重点,在构造方法中,我们需要传入一个IBookView,实际上我们的Activity已经实现IBookView了,所以这里实际上传的是具体的Activity,也就是this就行了。然后model我们可以直接new出来用,这里就new了。

    在initData中我们是进行了具体的网络请求,网络请求我们是不是要弹一个Dialog出来,直接在这mView.loading();调用就行了。然后请求成功onSuccess()里面让Dialog消失,提醒适配器刷新。失败的话onFail()里面提示Dialog消失,然后ListView设置失败页面什么的。


    1. public class BuyBookPresenter extends BasePresenter<BuyBookActivity> implements IBuyBookPresenter {  
    2.   
    3.     private IBuyBookView  mView;  
    4.     private IBuyBookModel mModel;  
    5.   
    6.     public BuyBookPresenter(IBuyBookView iBuyBookView) {  
    7.         this.mView = iBuyBookView;  
    8.         this.mModel = new BuyBookModel();  
    9.     }  
    10.   
    11.   
    12.     @Override  
    13.     public List<BuyBookBean> getAdapterData() {  
    14.         return mModel.getAdapterData();  
    15.     }  
    16.   
    17.     @Override  
    18.     public void initData() {  
    19.         //在这里弹出loading  
    20.         mModel.getTestData(new ValueCallBack<List<BuyBookBean>>() {  
    21.             @Override  
    22.             public void onSuccess(List<BuyBookBean> buyBookBeen) {  
    23.                 //在这里取消loading  
    24.                 //简单数据操作可以在presenter里完成  
    25.                 mModel.getAdapterData().addAll(buyBookBeen);  
    26.                 mView.refreshAdapter();  
    27.             }  
    28.   
    29.             @Override  
    30.             public void onFail(String code) {  
    31.                 //在这里取消loading  
    32.                 mView.showToast(code);  
    33.                 mView.onEmpty();  
    34.             }  
    35.         });  
    36.     }  
    37. }  


    接下来讲我们的Activity BuyBookActivity BaseActivity

    这是我们Acticity的基类,可以看到这里有个泛型,注意了,前方高能。这个泛型还必须继承BasePresenter,这个首先为了让人一看到这个Activity就知道对应着那个Presenter;其次最重要的就是为了下面那个成员变量basepresenter,我们写一个抽象的方法要求返回泛型T,而这个泛型T又继承了BasePresenter,那么我们就得到了具体Presenter的成员变量,可以直接用这个成员变量来调用Presenter中的方法了。


    1. public abstract class BaseActivity<T extends BasePresenter> extends Activity {  
    2.       
    3.     protected T basepresenter;  
    4.   
    5.     @Override  
    6.     protected void onCreate(Bundle savedInstanceState) {  
    7.         super.onCreate(savedInstanceState);  
    8.         setContentView(getLayout());  
    9.         initView();  
    10.         basepresenter = initPresent();  
    11.         onPrepare();  
    12.     }  
    13.   
    14.     abstract T initPresent();  
    15.   
    16.     abstract int getLayout();  
    17.   
    18.     abstract void initView();  
    19.   
    20.     abstract void onPrepare();  
    21. }  

    这个就是最终具体的Activity了,可以看到这里都没什么逻辑,基本都是一些重写的方法。

    1. public class BuyBookActivity extends BaseActivity<BuyBookPresenter> implements IBuyBookView  
    2. {  
    3.   
    4.     private ListView mListView;  
    5.     private BuyBookAdapter mAdapter;  
    6.   
    7.     @Override  
    8.     BuyBookPresenter initPresent()  
    9.     {  
    10.         return new BuyBookPresenter(this);  
    11.     }  
    12.   
    13.     @Override  
    14.     int getLayout()  
    15.     {  
    16.         return R.layout.activity_main;  
    17.     }  
    18.   
    19.     @Override  
    20.     void initView()  
    21.     {  
    22.         mListView = (ListView) findViewById(R.id.listview);  
    23.     }  
    24.   
    25.     @Override  
    26.     void onPrepare()  
    27.     {  
    28.         mAdapter = new BuyBookAdapter(this, basepresenter.getAdapterData());  
    29.         mListView.setAdapter(mAdapter);  
    30.         basepresenter.initData();  
    31.     }  
    32.   
    33.     @Override  
    34.     public void showToast(String msg)  
    35.     {  
    36.         Toast.makeText(this, msg, Toast.LENGTH_SHORT).show();  
    37.     }  
    38.   
    39.     @Override  
    40.     public void refreshAdapter()  
    41.     {  
    42.         mAdapter.notifyDataSetChanged();  
    43.     }  
    44.   
    45.     public void onEmpty()  
    46.     {  
    47.         mListView.setEmptyView(null);  
    48.     }  
    49. }  



    最后虽然MVP模式有许多好处,但是有一个致命的缺点就是类太多,本来一个类最多变成了7个类,最少变成6个类(使用Contract协议类)。所以并不是所有的页面都要用MVP模式的,很简单的页面就没必要了,浪费时间是不是。


    为什么MVP模式利于单元测试?

    Presenter将逻辑和UI分开了,里面没有Android代码,都是纯纯的java代码。我们可以直接对Presenter写Junit测试


    转载自:http://blog.csdn.net/qq_31852701/article/details/52946127
    原创粉丝点击