MVP模式

时间  2019-11-21
标签 mvp 模式 繁體版
原文   原文链接

转:http://blog.csdn.net/qq_31852701/article/details/52946127java

首先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这个协议类中，其实是同样的，这就看我的喜爱了，各有各的优缺点。好比宝宝的代码改为有协议类的这种就以下代码所示，看到了吧，实际上是同样的。 
public interface IBuyBookContract  
{  
    interface IBuyBookView  
    {  
        void showToast(String msg);  
  
        void refreshAdapter();  
  
        void onEmpty();  
    }  
  
    interface IBuyBookPresenter  
    {  
  
        List<BuyBookBean> getAdapterData();  
    }  
}

 


 



M（Model）
数据层，和MVC中的M同样，用来放数据的处理（好比网络请求，缓存等）。
 
V(View)
负责UI具体实现展示。好比Presenter派发过来一个动做是showDialog显示进度命令，那么咱们这个View就负责实现具体UI。
 
P(Presenter)
负责处理业务逻辑代码，处理Model数据，而后将处理完的数据分发到View层。

 

 

下面开始贴代码讲解

 

先来说View IBuyBookView

这里主要是包含了Activity的一系列关于UI操做，而后用咱们的Activity是实现，这样Presenter就能够调用了。

 

public interface IBuyBookView {  
    /** 
     * 提示toast 
     */  
    void showToast(String msg);  
  
    /** 
     * 刷新adapter 
     */  
    void refreshAdapter();  
  
    void onEmpty();  
}

 

 

接下来说Model IBuyBookModel  BuyBookModel

 

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

 

public interface IBuyBookModel {  
    /** 
     * 获取模拟数据 
     */  
    void getTestData(ValueCallBack<List<BuyBookBean>> callBack);  
  
  
    /** 
     * 返回本地adapter数据 
     * @return 
     */  
    List<BuyBookBean> getAdapterData();  
}

 


 

 

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

public class BuyBookModel implements IBuyBookModel {  
    private List<BuyBookBean> listData;  
  
  
    public BuyBookModel() {  
        this.listData = new ArrayList<>();  
    }  
  
    @Override  
    public void getTestData(final ValueCallBack<List<BuyBookBean>> callBack) {  
        new Handler().postDelayed(new Runnable() {  
            @Override  
            public void run() {  
                List<BuyBookBean> list = new ArrayList<>();  
                list.add(new BuyBookBean("赵云", 1, "09-27 09:11"));  
                list.add(new BuyBookBean("赵云、隔壁老王、小王、典韦、貂蝉、林芳、曹操、刘备、关羽、黄忠、张飞、诸葛孔明", 10, "09-27 09:11"));  
                list.add(new BuyBookBean("黄忠、孙权、大乔", 50, "09-27 09:11"));  
                list.add(new BuyBookBean("大乔、小乔、貂蝉、孙尚香", 300, "09-27 09:11"));  
  
                Random rd = new Random();  
                int N = rd.nextInt(10);  
                if (N > 5) {  
                    callBack.onSuccess(list);  
                } else {  
                    callBack.onFail("拒绝请求");  
                }  
            }  
        }, 1000);  
    }  
  
  
    @Override  
    public List<BuyBookBean> getAdapterData() {  
        return listData;  
    }  
}

 


 
 

这里贴上楼上那个回调接口，这里用了泛型，为何呢？为了多多复用。

public interface ValueCallBack<T> {  
    void onSuccess(T t);  
  
    void onFail(String code);  
}

 


接下来说Presenter BasePresenter IBuyBookPresenterBuyBookPresenter

这个是全部Presenter的基类，里面有个initData()方法，基本每一个Presenter都要处理网络请求吧，因此我就弄了这么一个基类，至于为何是抽象的而不是接口，这是由于抽象方便点吧，若是咱们往抽象类中添加新的方法（该方法不是抽象的），能够给他提供默认的实现，并且不要修改现有的代码，可是若是是接口的话，就要修改现有的代码了。指不定咱们之后要往这里加什么呢。

这里为何用了个泛型？为了让人一看这个Presenter就知道这对应着哪一个Activity,实际上这能够不加的，可是我以为加上去更好。便于后来人也便于本身之后再来修改这个类。

 

public abstract class BasePresenter<T extends BaseActivity> {  
  
    abstract void initData();  
}

 

 

 

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

public interface IBuyBookPresenter {  
  
    List<BuyBookBean> getAdapterData();  
}

 

这里首先实现现了IBuyBookPresenter继承了BasePresenter，而后重写一些方法。这里的构造方法是重点，在构造方法中，咱们须要传入一个IBookView，实际上咱们的Activity已经实现IBookView了，因此这里实际上传的是具体的Activity，也就是this就好了。而后model咱们能够直接new出来用，这里就new了。

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

 

public class BuyBookPresenter extends BasePresenter<BuyBookActivity> implements IBuyBookPresenter {  
  
    private IBuyBookView  mView;  
    private IBuyBookModel mModel;  
  
    public BuyBookPresenter(IBuyBookView iBuyBookView) {  
        this.mView = iBuyBookView;  
        this.mModel = new BuyBookModel();  
    }  
  
  
    @Override  
    public List<BuyBookBean> getAdapterData() {  
        return mModel.getAdapterData();  
    }  
  
    @Override  
    public void initData() {  
        //在这里弹出loading  
        mModel.getTestData(new ValueCallBack<List<BuyBookBean>>() {  
            @Override  
            public void onSuccess(List<BuyBookBean> buyBookBeen) {  
                //在这里取消loading  
                //简单数据操做能够在presenter里完成  
                mModel.getAdapterData().addAll(buyBookBeen);  
                mView.refreshAdapter();  
            }  
  
            @Override  
            public void onFail(String code) {  
                //在这里取消loading  
                mView.showToast(code);  
                mView.onEmpty();  
            }  
        });  
    }  
}

 

 

接下来说咱们的Activity BuyBookActivity BaseActivity

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

 

public abstract class BaseActivity<T extends BasePresenter> extends Activity {  
      
    protected T basepresenter;  
  
    @Override  
    protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(getLayout());  
        initView();  
        basepresenter = initPresent();  
        onPrepare();  
    }  
  
    abstract T initPresent();  
  
    abstract int getLayout();  
  
    abstract void initView();  
  
    abstract void onPrepare();  
}

 

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

 

 

public class BuyBookActivity extends BaseActivity<BuyBookPresenter> implements IBuyBookView  
{  
  
    private ListView mListView;  
    private BuyBookAdapter mAdapter;  
  
    @Override  
    BuyBookPresenter initPresent()  
    {  
        return new BuyBookPresenter(this);  
    }  
  
    @Override  
    int getLayout()  
    {  
        return R.layout.activity_main;  
    }  
  
    @Override  
    void initView()  
    {  
        mListView = (ListView) findViewById(R.id.listview);  
    }  
  
    @Override  
    void onPrepare()  
    {  
        mAdapter = new BuyBookAdapter(this, basepresenter.getAdapterData());  
        mListView.setAdapter(mAdapter);  
        basepresenter.initData();  
    }  
  
    @Override  
    public void showToast(String msg)  
    {  
        Toast.makeText(this, msg, Toast.LENGTH_SHORT).show();  
    }  
  
    @Override  
    public void refreshAdapter()  
    {  
        mAdapter.notifyDataSetChanged();  
    }  
  
    public void onEmpty()  
    {  
        mListView.setEmptyView(null);  
    }  
}

 

最后虽然MVP模式有许多好处，可是有一个致命的缺点就是类太多，原本一个类最多变成了7个类，最少变成6个类（使用Contract协议类）。因此并非全部的页面都要用MVP模式的，很简单的页面就不必了，浪费时间是否是。

 

为何MVP模式利于单元测试?

Presenter将逻辑和UI分开了，里面没有Android代码，都是纯纯的java代码。咱们能够直接对Presenter写Junit测试

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程