对Android中MVP的理解

软件发展这么多年,诞生出了很多有名的架构思想,小到设计模式,大到开发框架。当然,本篇文章要说的MVP,它既不是模式也不是框架,而是一种构建项目的架构思想。

那么有同学会问了,我为什么要用这些“多余”的,甚至可以说是繁琐的设计模式、框架或者架构呢。按常规套路,直观的开发模式不是很好么,而且很容易理解。

如果需要开发的应用比较简单,几个类加上一些开源的库就能搞定,那么就没必要整什么架构或者设计模式了,切忌为了模式而模式,为了架构而架构,那样就跟扛着大炮去打蚊子了一样,累死不说,效率还低的吓人。

然而在大型的面向大众的应用中,项目需求不断的更新迭代,引入架构的目的是为了简化代码的逻辑、便于协作开发、方便后期维护,说的高大上一点就是为了实现模块内部的高聚合和模块之间的低耦合。下面开始步入正题。

说到MVP就不得不提MVC了,MVP模式是由MVC模式延生而来的。先来看看MVC模式在Android项目中是如何体现的。

1、View层:一般对应xml中的布局。

2、Model层:比方说数据库存取操作,网络操作等。

3、Controller层:处理用户交互,比方说按钮的点击,手势的缩放滑动等等,向Model层发送请求,处理Model层的回调等。

无论小项目还是大项目,大部分同学在刚开始接触Android的时候基本都是采用类似的开发套路。

下面以实际案例来分析下MVC架构的应用。假设有这样一个需求,根据输入的城市编码获取城市天气信息。先来分析下这个需求,要求输入的地方肯定在View中处理,监听并发起请求在Controller中处理,获取城市天气在Model中处理,然后获取到数据后在Controller中拿到数据并处理之。下面用伪代码来模拟实际开发流程。

weather_activity.xml

WeatherActivity.java

Callback.java

HttpUtil.java

你看MVC架构用的不是好得很吗,为什么还要用MVP呢?

传统的MVC架构是Controller起到中间桥梁的作用,将Model和View隔离开来。而反过来再看下我们都做了什么?

HttpUtil

作为Model层,

main.xml

作为View层,

MainActivity

作为Controller层,而且Controller也确实做到了隔断M和V的目的,但是不知道各位有没有发现,MainActivity里面做的工作实在是太多了,上面示例很简单,但是在实际项目开发中,随着一个页面的逻辑复杂度不断提升,那么Activity中需要做的工作就会越来越多,以致变得庞大臃肿,一些复杂的页面,几千行代码写在一个Activity都很常见。这样不仅写起来异常麻烦,维护起来简直就是噩梦。而且相比较传统的MVC架构,在Android中,V和C区分的并不太明显,甚至可以说V和C都柔和到一起了。在Controller(Activity)中不仅要初始化界面,接收用户操作并作出响应,还要进行复杂的逻辑控制。

上面示例代码中介绍的开发思想适合运用在一些小项目并且是不需要单元测试的项目中,而一旦在大型的项目开发中,如果还是用这种开发模式的话,抛开上面提到的Activity臃肿的问题不说,测试人员测试接口是否通畅,mock数据都变得异常的复杂。

网上看到一篇博客也是介绍MVC在Android中的应用,这篇文章大家可以去看看,下面就根据这位老铁提供的思路改造下我们上面的示例代码。

IWeatherModel.java

OnViewListener.java

WeatherModelImpl.java

WeatherActivity.java

作者的做法和我的做法不同的地方就是他另外针对每个模块制定了一个接口,再去实现接口,该接口定义了Activity和Model交互的所有方法。这种实现的思路跟接下来我要说的MVP思想很类似,只不过更像是将MVP模式中M和P结合到一起的产物。这种写法的好处我觉得有以下几点:

1、接口的方式去实现Model,降低了Activity和Model的耦合度,正如作者说的那样,万一哪天需要替换网络加载框架,可以在不改变原有代码的情况去新增另外一个网络加载框架的实现类。

2、对测试来说也比较容易,可以不用实现一个Activity类来测试,只需要写一个java类实现IWeather接口就可以测试网络请求数据是否正确,另外也可以在

WeatherImpl

中mock数据来测试view的显示是否正确。

3、相较于第一种我的那种实现方式,将数据的处理部分都挪到了Model实现类中去做,解放了Activity,Activity只需要协调好View和Model就好了,它自己实际上还是既充当了View(因为view的初始化,赋值,控制等操作还是在Activity中执行)又充当了Controller,只不过更多的是充当了中间协调者的角色。

但是缺点有么?很显然是有的,小项目是看不出来,尤其是在大项目中,涉及到很多业务逻辑的处理,数据库操作等等,那么这些逻辑处理的代码甚至是控制代码都需要放到Model实现类中去写,这样随着业务逻辑复杂度不断提升,同样会造成Model臃肿的情况。那么怎么解决这种问题呢?答案是:再将Model分离!

聪明的工程师们于是乎将MVP思想应用到了Android项目开发中,以解决上面MVC带来的问题,说白了MVP的出现就是为了让Activity或Model得到解放,而MVP的思想也就是将上面第二种实现方式中的Model分离开来以M和P的姿态出现!

关于MVP架构谷歌给我们提供了一个很好的例子示范,接下来根据官方的示例作介绍,然后结合目前主流的MVP+Retrofit+RxJava框架来写一个简单的例子。先看下官方的示例程序的结构:

简单分析下,data目录下类的作用是获取本地数据和网络数据也就是Model,util目录存放工具类,BasePresenter和BaseView分别是基类,里面定义了最基础的方法,可以认为是所有模块必须要实现的方法。

BasePresenter.java

BaseView.java

其余目录对应项目中具体的模块,这里也给我们一个很好的示范,在实际项目开发中我也建议大家将项目分解成各个不同的模块,一般情况下我们可以根据项目中页面来定模块,比方说login登录模块,home首页模块等。这些模块都对应有ModuleActivity、ModuleContract、ModuleFragment、ModulePresenter四个文件,官方示例实际上是将Fragment作为View的,Activity只是起到初始化的作用,初始化Fragment和Presenter。

我们看下AddEditTaskActivity类节选

我们再看下AddEditTaskPresenter类节选

实际上整个页面的初始化,逻辑控制,发起请求等都在Fragment做的。我在实际项目开发中并没有将View分类,除非必须要用Fragment,要不然我都是将Activity作为View的。接下来我就根据官方提供的MVP架构的思路来写一个简单的例子。还是以根据城市编码获取天气的作为需求。

先看下项目的目录结构

weather_activity.xml

Weather.java

WeatherContract.java

WeatherModel.java

WeatherPresenter.java

WeatherActivity.java

可以看到Activity作为真正的View,没有参与任何逻辑控制,当然实际项目开发中看实际情况,可以适当的加入一些逻辑控制代码,但是获取数据源的操作都是通过Presenter来直接发起,并通过Model来直接获取,Activity只是对返回的数据和View绑定而已。对比上面说的第二种MVC的实现方式,Presenter充当的角色实际上是Model和View之前的桥梁,通过Presenter我们发起网络请求,并对返回的数据进一步处理,处理完成后通过接口的形式返回给View也就是Activity来使用。

这里是MVP代码 。

关于MVP和rxjava、retrofit的结合,网上很多博客介绍的都很清楚,我这里简单的说下思路,主要是将Model中的数据访问部分换成Retrofit,Retrofit本身就有对rxjava的封装,返回的数据类型是

Observable

类型,然后在Presenter中对返回的数据做进一步处理。下面是我的封装方式。仅供参考,大神勿喷。

同样的,先来看下项目目录结构

BaseEntity.java

BaseMVP.java

WeatherContract.java

WeatherModel.java

WeatherPresenter.java

这里是项目源码

跟第一种MVP实现方式不同的地方是Presenter我采用的是抽象类的方式,其实跟接口没什么本质的区别,主要是为了方便Presenter的实现类的使用,省去了既要实现接口又要集成BasePresenter。

最后再说几句,不论是MVC还是MVP思想,每个人都有自己的理解和实现方式,找到适合自己的才是最重要的。另外还是那句话,不要为了设计而设计,为了架构而架构,根据实际情况去考虑要不要选择架构,选择什么样的架构。

发表评论

电子邮件地址不会被公开。 必填项已用*标注