android 浅谈mvp模式

一，浅谈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