前言
MVP
架构流行已久,但由于实在没时间(太懒),所以一直对MVP
停留在听说一词上。由于最近公司让我接收一个android项目,而该项目之前的android版本就是使用
MVP
架构,因此得以真正接触到了MVP
架构。本文章Demo:点击下载
首先,我们来理解下MVP是什么?
MVP
全称Model-View-Presenter
,它把项目大概划分为3个模块,其实分别对应:M层:实体层,负责获取实体数据。
V层:视图层,对应
XML
文件与Activity
/Fragment
。P层:逻辑控制层,同时持有
View
和Model
对象。
MVP
的流程图大致如下所示:
那么,MVP有什么优势?
把业务逻辑抽离到
Presenter
层中,View
层专注于UI的处理。分离视图逻辑与业务逻辑,达到解耦的目的。
Presenter
被抽象成接口,可以根据Presenter
的实现方式进行单元测试。提高代码的阅读性。
可拓展性强。
同样,有优势就有缺点!
项目结构会对后期的开发和维护有一定影响,具体视APP的体量而定。
代码量会增多,如何避免编写过多功能相似的重复代码是使用
MVP
开发的一个重要处理问题。有一定的学习成本。
趁热打铁,撸起袖子就是干!
下面通过输入账号密码实现登录的例子,来看看
MVP
到底是如何分工(甩锅)合作的。
创建一个空项目,名为MVPDemo好了。然后在项目下的mvpdemo文件夹中新增model
、view
、presenter
三个文件夹,分别对应实体层、视图层、逻辑控制层。然后在view
文件夹中创建activity
文件夹,并把MainActivity
拖至其中。如下图所示:
在activity_main.xml
中添加三个组件,用于输入账号密码和登录
1 |
|
回到MainActivity
中,绑定三个UI组件
1 |
|
接下来就算是开始用到MVP
了,先来分析下登录操作,因为输入账号密码后需要进行登录操作,而登录操作可以看作有那么几步:
1.登录验证失败:账号密码不能为空,账号密码不能错误。如果存在这两种情况,则弹出对应
Toast
;2登录验证成功:弹出登录成功
Toast
,并跳转到登录成功页面
因此登录操作中既包括了逻辑控制层操作,也包括了视图层操作。
那么我们就需要创建对应的文件
1.在
presenter
文件夹下创建接口类LoginActivityPresenter
和impl
文件夹;2.在
LoginActivityPresenter
接口中新建一个登录方法;3.接着在
impl
文件夹内创建LoginPresenterImpl
类并实现LoginActivityPresenter
接口的登录方法;
1 |
|
1 |
|
在LoginPresenterImpl
中的完善login
方法,其中,因为需要在验证操作后通知UI层弹出Toast
操作,所以需要引入视图层的方法。所以在完善login
方法前,先来添加视图层需要的方法:
1.在
view
文件夹下创建iView
文件夹2.在
iView
文件夹新建一个接口类ILoginActivity
3.在接口类
ILoginActivity
中添加两个方法,一个用于验证成功后返回,一个用于验证失败后返回
1 |
|
万事俱备,只欠login
。我们回到LoginPresenterImpl
类,往里面引入刚刚添加的接口类ILoginActivity
,并完善登录验证失败/成功时的代码
1 |
|
现在基本的设置已经完成,我们把注意力移到MainActivity
身上,此时的MainActivity
还是独自一人,还没和逻辑控制层、实体层和视图层建立联系。因此我们来给他们搭建一座桥梁:
1.引入逻辑控制层
LoginPresenterImpl
1 |
|
2.为
LoginPresenterImpl
新建实例对象
1 |
|
3.触发登录事件时,调用
LoginPresenterImpl
(逻辑控制层)里的login
方法
1 |
|
4.实现接口类
ILoginActivity
(视图层)的两个方法,并在各自的中实现对应的逻辑
1 |
|
1 |
|
5.同样的,如果有保存用户数据的需要,也需要实现前面3、4的操作
总结
到这里为止,MVP的分工合作就已经配置完成。现在也应该对MVP的操作有一定程度的了解了。其
核心是逻辑控制层,所有的UI操作和数据操作,都是经过逻辑控制层来分派的。它的存在就像是你的BOSS,分派不同的任务给下属,专业的事情由专业的人来干!
最后放上效果图: