Android中使用MVP模式简介

经常在各种地方看到有人提到MVP，在Android的开发中MVP模式越来越流行，我这里也学习和总结一下MVP模式。 本文参考自：MVP for Android, The Clean Architecture以及Resources for Learning Dagger for Android。

软件架构的依赖规则：

软件是分层的，高层是基础业务逻辑和策略，低层是实现机制和展现形式。代码和数据依赖只能是低层代码依赖高层，而不能反过来。

什么是MVP？

MVP是Model, View和Presenter的简称。是非常有名的MVC模式的演化版。MVP模式把显示逻辑和从业务逻辑层中分离出来，理想状况下，MVP模式中，在替换不同的视图(View)的情况下，可以实现完全相同的业务逻辑。

Presenter代替了MVC中Controller，它比Controller担当更多的任务，也更加复杂。Presenter处理事件，执行相应的逻辑，这些逻辑映射到Model的Command以操作Model。那些处理UI如何工作的代码基本上都位于Presenter。Presenter如同一个乐队的指挥家，表现和协调整个Application，它负责创建和协调其它对象。

MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

为什么使用MVP模式

因为在Android中，Activity严重耦合了界面和数据获取层。这样不仅导致了Activity的类越来越庞大，而且，如果修改数据获取层，可能也导致整个View都要重写。也非常不利于模块和自动化测试。

MVP使View独立于数据，把大量的逻辑从Activity中提取出来。把应用分层，每层都可以独立测试和变动。

MVP模式是如何工作的

MVP模式中的角色划分并没有标准的划分方法。大致的定义如下：

• 表示器(Presenter)
  表示器也可以称为指挥器，它处在View和Model之间，负责从Model中获取数据，然后返回给View。同时决定视图上的交互的处理。
• 视图(View)
  视图比较好理解，在Android中一般对应的是Activity，Fragment或者View。因为视图上的交互需要通知表示器，让它决定做什么事情。所以View中一般包含一个Presenter的引用。理想状况下，Presenter一般使用依赖注入的方式实现。
• 模型(Model)
  模型是应用程序中的数据处理和业务逻辑部分。

MVP处理流程如下图所示：

注：图片引自http://www.360doc.com/content/10/0225/18/86732016805936.shtml_

用户的请求首先会到达View，View传递请求到特定的Presenter，Presenter从Model获取数据后，再把处理结果通过接口传递到View。

本文写完后，发现没有实际实践例子，读者可以深入阅读文中的参考文章，里面有相关的实例。我会在后面的博文中继续记录学习使用MVP模式的过程。