MVP模式优化与进阶

MVP作为近段时间比较流行的架构，相信大家都有一定了解，所以这里不再阐述MVP的基本概念与优缺点。本文重点在于从自身项目出发，归纳整理的一些MVP的一些心得体会，如果能对大家有所帮助和启发，万分荣幸。

首先来说说使用了MVP近一年后，现在项目中MVP的变化。传统MVP模式，大家都知道是以activity或fragment为View，然后同时创建一个Presenter和Model类，并且View持有Presenter的实例，Presenter持有View和Model的实例，然后通过接口解耦，表面上看上去似乎没什么不对，但仔细想想Presenter与View互相持有引用其实隐形的加大了耦合，并且非常容易造成逻辑不清，也许是应该放在Presenter里的方法被放到View中。并且传统的MVP还有一大问题在于以activity为View,我们都知道activity是有生命周期的，MVP模式又将主要业务逻辑交给了Presenter去处理，这样就非常容易造成activity泄漏或者引用空指针。幸好偶然间看到一篇别人的文章，MVP本身就不是死的，为什么一定要以activity为View呢？豁然开朗，以activity为Presenter其实更好用，activity为Presenter后，View可以不再持有Preseter的引用了，Presenter与View间的耦合进一步降低，因为耦合减小所以P与V的交互也变少了，大大简化了逻辑，传统MVP与新型MVP的交互示意图如下：

而且因为现在activity本身就是Presenter,所以基本上不用太操心生命周期的问题了，最后再说说这种MVP的缺点，这种MVP的写法相较于传统MVP最大缺点在于以activity为Presenter的话，activity中的代码相对传统的多一些，毕竟由View变成Presenter，相应的解决方法是Presenter中只存放主业务逻辑或Model与View调用较多的逻辑，复杂的View或Model逻辑由对应模块自己去实现，比如，读取数据库中的数据逻辑，Presenter只管获取数据而不去管怎么从数据库中取出来，取出来的过程交由Model，Model经由一系列复杂逻辑取出数据并提供出去，并不去管谁用了这些数据。同样的，Presenter从Model拿到数据后传递给View，具体View要怎么显示，会隐藏或显示某些控件，这些Presenter都不去关心，这些由View自己控制。

当然，以上只是个人的一些看法，可能有的人会觉得这样搞混了MVP的职责，但是MVP也好，许多设计原则也好，其实都是相对灵活的，哪怕是很多系统级源码，也会出现某些代码违背了一些原则，毕竟原则是死的人是活的，重要的是自己能把握这个度。