深入浅出Android MVP模式

什么是MVP模式

MVP是针对有GUI存在的应用程序，比如像安卓，像水果以及PC的客户端软件中用以划分组织代码的一种设计模式，是由MVC模式升级演进出来的，目的在于，对于GUI层来说，把UI展示与逻辑分开。

Model – 为UI层提供的数据，或者保存UI层传下来的数据View – 单纯的展示数据，响应用户操作并都转发给Presenter来做具体的处理Presenter – 逻辑控制层，从Model处取数据，运算和转化，最后用View来展示；并处理View传过来的用户事件，并做处理。

需要注意的是MVP仅用于应用中的GUI部分，它并不是整个应用的架构方式。一个应用的主要的架构应该包括基础组件，业务逻辑层和GUI展示层，而MVP仅是用于展示层的设计模式。另外，它是一个方法论的东西，没有固定的实现方式，只要能体现出它的方法就可以算是MVP。

虽然是方法论，但是也有一些指导性的原则来约束实现：

Model与View不能直接通信，只能通过Presenter
Presenter类似于中间人的角色进行协调和调度
Model和View是接口，Presenter持有的是一个Model接口和一个View接口
Model和View都应该是被动的，一切都由Presenter来主导
Model应该把与业务逻辑层的交互封装掉，换句话说Presenter和View不应该知道业务逻辑层
View的逻辑应该尽可能的简单，不应该有状态。当事件发生时，调用Presenter来处理，并且不传参数，Presenter处理时再调用View的方法来获取。

从这里可以看的出来，其实，MVP的目的就是把GUI的逻辑都集中在Presenter层，又把View层和Model与其用接口分离，让View尽可能的简单，这样可以加强移植性。因为View层是肯定不能移植的，不同的平台GUI的窗口部件肯定不一样，Model也是不太好移植的，因为每个平台的IO也都是不一样的。但是，MVP中的P肯定是可以移植的，因为它里面只有逻辑，且View和Model都是接口，所以很容易移植。同时，因为View和Model都是接口，这个Presenter也非常好测试，只要实现一个View的接口和Model的接口，就可以单独的测试Presenter了。

严格来讲，View只是被动的显示，提供方法由Presenter来调用，数据等都是由Presenter来提供，内部不能任何的逻辑与状态，逻辑和状态都应该是在Presenter中。UI事件发生时，调用Presenter的方法来处理，不能传参数，也不能有返回值，在Presenter中处理后再调用View来更新数据和状态。

MVP与MVC的区别

MVC之中逻辑是放在了Model里，Controller负责桥接View和Model，View发生变化时通知Controller，Controller再通知Model，Model进行逻辑处理，更新数据，然后通知View来刷新。可以看到MVC中三者之间都有联系，如果处理不好，或者当View比较复杂时，三者之间都会双向关联。MVC在命令行应用，以及WEB中有大量的应用，但对于客户端（PC和移动端）的GUI应用，MVC往往解决不了复杂性，移植性上以及可测试性上也没有优势。

MVP的改进在于：

逻辑放在Presenter中View和Model抽象成为接口

这样就带了二个好处：

代码更加容易移植代码更加容易加入Unit Testing

如何在安卓中实践MVP

MVP是一个方法论的东西，也就是没有任何固定的具体的实现形式，只要能够把View跟Model解除联系，把逻辑都放在Presenter中，那么就能算得上是MVP，一些具体的实践的指导性原则：

View是一个接口，负责被动的把处理好的数据显示出来Model也是一个接口，负责获取数据和存储数据View调用Presenter处理用户事件也是一个接口，称为事件DelegatePresenter持有的是View的接口和Model接口

安卓的Activity是一个比较奇葩的角色，在MVP中，既可以用作V，因为一个应用的根布局总是由Activity来创建的。当然也可以当作P，因为Activity是一个应用的入口，也是出口，再加上一些关键的系统事件也都是通过Activity的方法来通知的（比如configChange, saveInstance）。其实，都可以。因为MVP是方法论，并没有固定的形式，只要是把数据处理的逻辑都封装在Presenter里，让其去控制View和Model，让Activity来承担View还是Presenter，其实都可以。