打造Android MVP模式（一）

最新推荐文章于 2024-07-25 20:15:49 发布

Nowy

最新推荐文章于 2024-07-25 20:15:49 发布

阅读量849

点赞数 2

分类专栏： android 文章标签： android mvp

本文链接：https://blog.csdn.net/wu8285/article/details/52118418

版权

android 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

mvc和mvp

mvc:模型(model)－视图(view)－控制器(controller)
mvp:模型(model)－视图(view)－主导器(Presenter)

咋看之下，mvc和mvp没多大区别，就是C层换了个名字变成P层了。
真的是这样么？其实他们的区别可以通过下面这张图来区别他们的异同

mvc和mvp区别

通过上图，其实可以看出两种不同的理念，虽然都是3个模块，可是它们说负责的职能却是不一样。
如果对它们的职能感兴趣的童鞋可以参考一下的几条连接，这里不再详细描述。
MVC, MVP, MVVM比较以及区别
http://www.cnblogs.com/JustRun1983/p/3679827.html
http://www.cnblogs.com/JustRun1983/p/3727560.html

MVP的引入

Android开发模式本来就是遵循着mvc模式，
activity代表着controller，
各种数据获取组成的数据源代表了model。

这个mvc由Android框架自身维护着，不需要我们添加其他代码。
可是，在实际的开发过程中，activity除了业务逻辑，还要包含对view层和model层的引用。随着功能的增加activity会越来越臃肿。
这对于项目的维护和迭代更新是非常不利的，项目更需要模块间的松耦合，模块内的高内聚，自身职能明确的同时减少对其他模块的耦合。故MVP渐渐被大多数人看好。

Android中MVP的运用

MVP模式在Android中的运用主要是，明确好m层，v层和p层。
在MVP模式中
View层：activity/fragment会作为view层，内聚view所包含的功能，对外暴露调用api
Model层：也就是数据源，内聚了数据的获取，对外开放数据接口
Presenter层：内部编写业务逻辑，同时从m层获取数据，根据业务展现在view层上
PS：其实也有其他实现，例如：theMvp。这个主要看自身需求而定

由于MVP的模块关系是我们自己维护的，为了后期的扩展，普遍把关系搭建在抽象上面，所以在MVP项目中，我们可以看到很多接口。

MVP模式实战

归纳说多了，这里来点实际的代码。

首先来个项目结构图：

结构说明:

domain:
- model:数据结构，其实就是一些javabean
- repository（抽象）:这里面都是抽象接口，主要提供给repository层实现

presentation:
- presenter：主要实现业务逻辑
- ui : ui的搭建和编写

repository（实现）:数据源，主要实现数据的获取（网络或者本地）

utils:工具类

domain层代码结构：

domain层代码结构

model层很简单，就是一个普通的Javabean，这里就不过多介绍了；
repository（抽象）层，这里的repository其实只提供了接口，不提供实现方式

repository（抽象）层

就和上面截图所展示的，repository（抽象）层中只是定义了需要获取的数据的接口，而不需要具体实现

repository(实现)层代码结构

repository(实现)层代码结构

NetWeatherRepositoryImpl的代码

从上述截图可以看到，我的repository(实现)层中的代码分成3个模块：
1.Impl包：主要是对repository(抽象)层接口的实现
2.interfaces:主要存放接口
3.network：网络访问模块

其实这一层思路很简单，就是实现repository（抽象）层的接口，至于具体实现就看业务要求，我这里选用的是网络获取数据，用的是retrofit，所以我加多了一个interfaces用以存放，网络访问的api

至于network层，其实就是retrofit的初始化和整合，这里先不做具体分析，等下一章MVP+Retorfit+RxJava的时候再进行具体分析

3.presentation层的代码结构

presentation层的代码结构

这个层下面的目录结构比较多，不过主体分为两个模块
1. presenters
- base层 : 一些基础和通用的定义，抽取出来的基类
- interfaces层 : presenter的接口的存放
- impl层 : presenter接口的具体实现
2. ui
- activities 层 : 存放activity的目录
- app : 项目app
- base层： view层抽取出来的基类

看到这里，是不是纳闷ui层好像少了一个interfaces层，用于存放view的接口呢？
其实答案在这里：

presenter

在presenter的就接口里定义了一个内部接口，这不仅减少了命名的冲突，也更好的表达了它们之间的联系

项目结构分析完之后，我们来看看它们的运行原理
如果我们只看抽象类的话，我们可以得到：

IRepository <- IPresenter <-> IView

怎么理解呢？
用户点击手机屏幕，视图层（IView）收到用户的操作，向主导器(IPresenter) 发送了请求数据，
主导器(IPresenter)通过参数和业务，根据条件从 数据源(IRepository) 获取到了数据，
然后主导器(IPresenter)把数据展现在视图层（IView）上