不一样的mvp

mvp出来好久了，一直没有用它，一是最近项目要求太急自己对mvp又不熟悉；二是自己太懒，当然最主要还是自己太懒。以前在网上看到过很多描述mvp的各种好的，但是我看了过后一头雾水，总觉得何必将很简单的东西弄得这么复杂，基本上每个业务逻辑都要新建很多类，自己觉得没有必要。但是有时候看自己写的东西都会觉得“写的什么玩意儿”，这次趁着有大把无聊的时间，打算重新来看看这个被众多程序猿所争论的mvp架构模式。好了废话不多说，以下是我花了一个半小时自己亲自实践了一把，总结了一些。

还是一贯的套路，要说mvp就先说mvc,不过我自己觉得mvc架构其实就是最基本但是最经典的架构，但是1000个程序猿就有1000个mvc，但是大体上都是这样的：
mvc层架构
1、model层
就简单的理解成了数据实体类层
2、View层
这个就更离谱了，有些人知道View层其实是界面层，但是这样的话control层又是什么东西，就干脆将我们的View直接理解成了布局文件。
3、control层
有了第二步的自欺欺人过后，有些人会写个控制类的层级，但是很多人就将Activity直接当成control来用了，于是就出现了超级Activity；

这样写如果项目小而且只有一个人开发那还差不多，但是人多了过后，就会出现看不懂的尴尬了，最后就导致了自己写的东西只有自己能维护，这样团体开发的优势就不能体现了。特别是将activity当作control层来用，这对于维护是相当麻烦的事情。

mvp层架构，是从新定义了一下这个modle View Presenter 这三层；
1、model层
网上很多人将Modle层还是理解为实体类，但是通过实践，我觉得model层和实体类根本就不是一个概念。Model层最主要的职能是获取我们的数据然后封装成我们的实体类供presenter实例调用，当然，我们的model层也不是一个业务逻辑就要建一个，比如和用户相关的我们建一个UserModel，里面包含了登录，注册，密码修改等等和用户相关的，然后在里面写上各自的方法和需要的参数和回调。
2、View层
View层也不单单是布局文件，而是整个Activity,这个层最主要的职能是将我们界面上的数据获取出来供Presenter调用，或者是让Presenter调用View界面达到更新UI的目的.在这一层基本就需要一个逻辑结构写一个了，这里面持有相关的Model实例。
3、presenter层
而所有的用户界面交互逻辑着全部写在presenter层里面。presenter层里面同时持有View层（Activity）的实例和Model层的实例，通过model可以得到我们想要的数据，然后通过View层也可以得到我们界面的数据以及更新界面。

这样这三个层次各自的职责就非常清晰了。只有清楚了每个层各自的职责，我们写起来才会非常清楚。关于具体实现，我这里就不在赘述了，网上有很多例子，当然大体各层职责范围清楚了过后每个人怎么写都可以，毕竟思想才是最主要的。