【Android - 框架】之MVP模式的使用

提起MVP架构模式,大家可能首先想到的是它的“前辈”MVC模式。MVC由Model、View、Controller组成,请求从Controller进入后进行业务判断,然后交给Model或View进行处理。这本身没什么,但是应用在Android程序中时,大家就会发现,Activity既担任了Controller的角色进行业务筛选,又担任了View的角色进行界面展示,甚至有些时候还会担任Model的角色加载数据。这就使的Activity中的代码变得很多很长,而且功能杂乱,不便区分。怎么办呢?于是,MVP模式就诞生了。

MVP由Model、View和Presenter组成,和MVC相似,MVP中的Model层也是用来加载数据的,View层也是用来展示界面的,MVP中独有的Presenter是用来连接Model和View两层,起到解耦的作用。下图展示了MVC模式和MVP模式的工作流程上的比较:

从图中可以看到,MVP模式中的View层和Model层之间没有连线,即这两层之间没有直接的关联,它们之间的交互是通过Presenter来完成的,这样就实现的View和Model两层的解耦。具体的MVP内部的工作流程如下图所示:

可以看到,用户首先在View层中进行操作,将用户动作传到Presenter中,Presenter将动作传递到Model中进行处理,然后将处理结果传回到Presenter,再由Presenter相应到View中。

MVP模式的整体架构是通过接口来搭建的,我们需要一个整体的架构管理类Contract来管理Model、View、Presenter这三个接口,Model类、View类和Presenter类都分别实现这三个接口。Presenter中持有Model和View的引用,Presenter中的所有方法都会调用Model中对应的方法进行处理;Model中写实际代码;View是被Activity实现的,其中持有一个Presenter的引用,所有方法都会调用Presenter的对应方法。

下面贴出一个简单的DEMO中的代码。

DEMO的界面非常简单,只有一个按钮,当我们点击按钮的时候弹出一个Toast,就是这么一个简单的DEMO,我们尝试用MVP模式来搭建,编写。

首先我们需要一个接口的统一管理类MainContract,这个类中包含了M、V、P三个接口,接口中定义抽象方法。这里我们只打算有一个方法,即按钮点击事件onButtonClicked()方法。代码如下:

public class MainContract {

    interface View {
        void onButtonClicked(String text);
    }

    interface Model {
        void onButtonClicked(Context context, String text);
    }

    interface Presenter {
        void onButtonClicked(Context context, String text);
    }
}

有了接口之后,我们让M、V、P三层的具体类来实现这三个接口,这三个类分别是:M层对应MainModel,P层对应MainPresenter,V层对应MainActivity。

我们来编写MainPresenter类中的代码,首先需要让它实现MainContract类中的Presenter接口,然后为它设置两个属性,一个是Model,一个是View,在构造方法中传入View,并初始化Model,最后实现Presenter接口中的方法并调用Model中的对应方法实现。MainPresenter类中的代码如下:

public class MainPresenter implements MainContract.Presenter {
    private MainContract.Model model;
    private MainContract.View view;

    public MainPresenter(MainContract.View view) {
        this.view = view;
        this.model = new MainModel();
    }

    @Override
    public void onButtonClicked(Context context, String text) {
        model.onButtonClicked(context, text);
    }
}

接下来是MainModel类中的代码了。MVP中的所有具体逻辑实现的代码都是在Model层中编写的,因此在MainModel实现Model接口的onButtonClicked()方法中,我们按照需求弹出一个Toast即可。代码如下:

public class MainModel implements MainContract.Model {
    @Override
    public void onButtonClicked(Context context, String text) {
        Toast.makeText(context, text, Toast.LENGTH_SHORT).show();
    }
}

最后就是View层的编写了。上面说过,View层的实现类就是Activity,View层中需要持有一个Presenter的引用,View层中的所有操作都调用Presenter层中对应的方法,而Presenter层都是调用Model层的代码,因此View层就算是间接的调用了Model层的代码。MainActivity中的代码如下:

public class MainActivity extends AppCompatActivity implements MainContract.View {
    private MainPresenter presenter = new MainPresenter(MainActivity.this);

    @InjectView(R.id.btn)
    protected Button button;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // 初始化ButterKnife
        ButterKnife.inject(MainActivity.this);
    }

    @OnClick(R.id.btn)
    protected void click() {
        onButtonClicked("Button Clicked!!!!");
    }

    @Override
    public void onButtonClicked(String text) {
        presenter.onButtonClicked(MainActivity.this, text);
    }
}

到此为止,MVP的一个简单的DEMO就完成了。MVP只是一种思路,每个人都有每个人的理解,因此架构的搭建会有所不同,但整体的目标是不变的,那就是让Activity中的View层和Controller层分离开来,减少Activity中的代码。

当然,MVP模式也有缺点,那就是每创建一个Activity,就需要再创建Contract、Model、Presenter三个类,会大大增加项目中的类的个数。

时间: 12-20

【Android - 框架】之MVP模式的使用的相关文章

Android上实现MVP模式的途径

今天我想分享我在Android上实现MVP(Model-View-Presenter)模式的方法.如果你对MVP模式还不熟悉,或者不了解为什么要在Android应用中使用MVP模式,推荐你先阅读这篇维基百科文章和这篇博客. 使用Activity和Fragment作为View合适么? 目前,在很多使用了MVP模式的Android项目中,主流做法是将Activity和Fragment作为视图层来进行处理.而Presenters通常是通过继承被视图层实例化或者注入的对象来得到的.我认可这种方式可以节省

Android开发中MVP模式浅析

目前为止,MVP的使用还没有一个标准,在此先记录一下目前学习到的一些Android中使用MVP的知识. 按传统的方式开发,经常会使Activity中混杂着UI交互,业务逻辑等流程.而MVP模式能巧妙的解决这个问题.先直接上一个小例子吧. /** * 定义一个对UI组件进行操作的接口,让Activity实现这个接口 * @author Quinn * @date 2015-5-9 */ public interface LoginView { public void showProgress();

Android上的MVP模式

什么是MVP? MVP模式可以分离显示层和逻辑层,所以功能接口如何工作与功能的展示可以实现分离,MVP模式理想化地可以实现同一份逻辑代码搭配不同的显示界面.首先要澄清就是MVP不是一个结构化的模式,它只是负责显示层而已,任何时候都可以在自己的项目结构中使用MVP模式. 为什么要使用MVP? 我们知道在Android上逻辑接口和数据存取是紧耦合的,这个问题可以看看CursorAdapter这个例子,它既融合了适配器,同时也有显示的成分,而cursor很大程度上应该是数据数据存取层的. 对于一个可扩

Android开发之MVP模式的使用

前几天发现,在Android项目代码里有一个Activity类行数居然有1000多行,而600行左右都是逻辑控制,真正和页面控件处理相关的代码不多,虽然可以用#region <>...#endregion块包起来,但是整体来说,页面和逻辑处理揉得太紧密了,有时代码复用起来也不方便,于是,决定重构,找了一下,有MVP(Model-View-Presenter,Model层负责数据管理,View层负责页面控件数据展示与设置,Presenter负责逻辑处理,控制View层如何显示与展示数据,这种层次

Android之 用MVP模式 来实现webview 历史记录保存与显示

MVP在android上是常见的一种设计模式,在Launhcer,手机浏览器里面经常会看到,观摩了下其他大神写的,现在总结下,操刀起来写个demo 有什么问题的地方请提出来. 大家一起研究讨论. demo 下载地址;http://download.csdn.net/detail/xufeifandj/8267619 demo主要是 主页是一个webview,实现了 历史记录的添加,与显示.例子比较简单. 整个项目的结构如下: HistoryPresenter.java 主要是对view与mode

在Android上用MVP模式编程的实践

首先,谁是V?谁是P?(M我认为不是问题) View,应该是实现显示逻辑,在Android开发中,我们认为Fragment.Activity都可以被当做View,他们主要任务就是控制显示逻辑,这部分代码不太经常重用.View通过调用P的业务逻辑,来实现业务.业务包括同步的业务(可以在UI线程操作)和异步的任务(如网络.磁盘IO等耗时操作),并根据P的业务返回结果来响应地改变UI. 对Presenter的实现,我们用AndroidAnnotations框架的EBean实现(如果不熟悉这个框架,请G

Android开发学习--MVP模式入门

1.模型与视图完全分离,我们可以修改视图而不影响模型2.可以更高效地使用模型,因为所有的交互都发生在一个地方--Presenter内部3.我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑.这个特性非常的有用,因为视图的变化总是比模型的变化频繁.4.如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试) 下面示例一个小案例: 项目架构: 首先bean层: User.java public class User { privat

google官方架构MVP解析与实战-(从零开始搭建android框架系列(3))

最近更新2016.5.10(已经添加整个项目目录.更新新闻资讯) 本篇文章项目github地址:MVPCommon 本文章原地址:简书博客 1 前言 当然对于MVP的解说也是使用也是层出不穷,我也网络上也能看到各种版本的解说,之前博客也有文章的更新,里面有MVP的详细说明和项目代码->Android中的MVP模式,带实例. 本篇文章将参考 google官方android MVP架构项目的实现,来实现自己的项目.或许看了这篇文章之后,你再去梳理一下google官方架构项目,会让你收获更多.官方的实

Android架构篇--MVP模式的介绍篇

摘要: 在MVVM成熟之前MVP模式在Android上有被神化的趋势,笔者曾经在商业项目中从零开始大规模采用过MVP模式对项目进行开发.在使用MVP模式进行开发的时候发现项目的结构模式对开发是有一定的影响的,在这里笔者会对这一问题进行探讨.希望通过这篇blog能让读者了解如何使用MVP模式搭建一个功能完善的MVP模式开发框架,避免一些笔者认为比较严重的问题. 为什么要使用MVP模式 在传统的Android开发中,我们一般是使用MVC模式进行开发的.传统MVC模式介绍: View: 视图层,对应x

MVP模式

在传统的Android开发中,我们一般是使用MVC模式进行开发的. 传统MVC模式介绍: View: 视图层,对应xml文件 Controller: 控制层,对应Activity和Fragment层,进行数据处理 Model:实体层,负责获取实体数据 在Android开发中采用MVC模式的一个最大的弊端就是xml作为View层视图能力实在太弱,所以一般情况下我们都是通过Controller层来辅助处理一些视图的.这样的结果就导致Controller既作为控制层的同时又承担了View层的大部分功能