前言##
在日常开发APP 的过程中，随着业务的扩展，规模的变化。我们的代码规模也会逐渐变得庞大，每一个类里的代码也会逐渐增多。尤其是Activity和Fragment ，由于Context 的存在，基本上所有对视图的操作我们只能在Activity和Fragment中完成；即便是对某些逻辑进行封装，Activity和Fragment 依旧会显得过于臃肿。因此，我们需要换一种思路去写代码，这个时候MVP模式就应用而生了！那么MVP 怎么用呢，下面就来说一说。
假设你现在如要实现下图中的功能：
arch.png
如图中所示，使用MVP 架构之后，多出了许多类；这是必然的；每一个View（Activity或Fragment）都至少需要各自的Model、Presenter和View接口，在加上他们各自的实现，也就是说每一个页面都会有6个java文件（算上Fragment或Activity，因为他就是View的实现），这样一个稍有点规模的APP，类就会变得异常的多，而每一个类的加载又会消耗资源；因此，相较于MVC，这算是MVP最大的缺点了吧。
当然，对于这个问题我们可以通过泛型参数、抽象父类的方式，将一些公用的Model及Presenter抽象出来。这应该就是使用MVP架构的精髓了。
最后##
个人感觉，使用MVP 架构是利大于弊的；随着项目规模的增加，代码逻辑的清晰才是最重要的事情。况且Google官方也出推出了一系列关于MVP的使用demo。因此，这也是官方提倡大家使用的。凡事，有利必有弊；类数目的增长是无法避免的事情，因此如何使用泛型和抽象优化MVP 的结构就变成了我们用好MVP的关键了。
当然，我们不能为了MVP而去MVP，如果项目结构不是很庞大，业务不是很复杂；那么传统的MVC 架构足以，而且也方便！
年前的最后一个工作日了，我居然写了一篇学习笔记；今天一定是上了假的班儿！明天回家过年，O(∩_∩)O哈哈哈~！每一个人，新年快乐！
网友评论