一,浅谈mvp
为什么说是浅谈呢,因为目前在我看过的mvp代码风格不统一,在我们公司就存在两种(当然现在统一了),所以本人到目前为止还没真正理解mvp(理解能力有待加强),并且有段时间还是吐槽一大堆的,因为自从写了mvp,接口、类多了n个,原本简单的view操作变得复杂。但时间长了,也是体会到了一丁点它的优点的(目前就一丁点,哈哈)。
mvp我认为是在原先的mvc模式上进行的优化,其实之前我写的代码mvc都不算吧,因为之前mvc之中的view层也就是Activity/fragment负担过重,角色并不是单一的view层,耦合性较高。而mvp的一个明显的特点就是解耦,将view层与model层完全解耦,presenter层充当两者之间的桥梁。
对比一下两者结构框图(盗图):
mvc:
mvp:
也就是把业务逻辑抽了出来,与view层解耦。不仅能让activity变得清爽,还便于复用。
二,用法
下面看一个简单的登录的例子。
我习惯按模块分,因为后期想改东西的时候根据包名好找。
可以看到,我建了四个包,view(写成iview了)、presenter、bean,biz。很奇怪,为什么只有m、v、p三层,我却建了四个包。说一下这个里面每个的职责。
1.bean
很简单,就是用到的实体类。
2.view
activity及view接口,属于view层。iview里有三个方法,activity的获取(因为presenter中toast等得用到当前类对象的)、等待框的显示与隐藏、登录成功后逻辑处理。
activity里主要任务是findviewbyid、调presenter层方法及实现iview接口中的方法:
在这里,我用到了userbean,可能有疑问了,这个不是属于model层的吗?不是说,m、v层完全解耦的吗?这个我也很困惑。因为就比如说,项目里有个activity,里面有很多editext,点击提交按钮,提交数据,我总不能去在iview里一个个的写获得这些值得方法吧,那这样就违背了让acticity简洁的初衷(我是这样认为的),并且这里只是赋值,并没有其他操作,很多情况下我们也许会new一个空的实体类,具体的值会在presenter逻辑层里获得,然后返回给view层。
3.biz层
为什么多出来了biz层了呢,我的理解是为了biz层逻辑代码的复用,并且我现在的代码习惯是v和p是一一对应的。所以当出现多个模块共用一个功能的时候,我只需要重新写一个presenter,实现biz里的方法就可以。
在这个biz写逻辑代码,一般会有两种状态,成功和失败,所以写了个接口回调。方便与presenter与view层的通信,通知view层成功还是失败,方便view层采取措施。
4.presenter
再来看presenter层,因为逻辑代码抽到了biz层,所以presenter只需调用biz层的方法就ok。
这里,可以看到presenter层用到了biz,和iview,我认为biz处理逻辑的职责,其实就是处理数据,其实是属于model层的。(不知道这样想对不对),所以这里可以看出来,presenter是model和view的桥梁(感觉这样建立在我把biz属于m层的基础上,所以说,理解的不深了。还望有理解的人指点迷津。)
ok,这就是我目前所理解的mvp模式。之前有个版本是没有biz层的,然后presenter里通过view层传了各种参数,并且逻辑复杂的presenter层依旧很混乱。所以现在就采用这种。目前对于mvp还处于摸索转态,欢迎一起讨论。
参考文章:Android MVP模式 简单易懂的介绍方式 - 中二病也要开发ANDROID - SegmentFault
https://segmentfault.com/a/1190000003927200