MVP for Android: 如何组织显示层的内容

MVP（Model View Presenter）模式是从众所周知的MVC（Model View Controller）模式中派生出来的，目前在Android开发中变得越来越重要。越来越多的人在谈论MVP，但实际上可靠的、结构化的资料很少。这就是我写这个博客的原因，通过它鼓励大家讨论，然后把我们学到的MVP知识以最好的方式应用到我们项目中来。

什么是MVP？

MVP模式允许从业务逻辑中拆分出表示（presentation）层，因此，所有关于UI界面的东西可以从中分离出来。理想的MVP模式就是在相同的逻辑下，由于View是可互换的，可以有完全不一样的展示效果。首先要澄清的是MVP并不是体系结构模式，它只负责表示层。在任何情况下，我们都可以在项目中使用它。

为什么要使用MVP？

在Android开发中有一个问题是来源于Android 中逻辑接口与数据访问机制是紧密耦合的，我们可以找到像CursorAdapter这样极端的一个例子，这是一种混合式适配器，它既融合了适配器，又有View的成分，而cursor很大程度上应该是访问层的，所以应该降低数据访问层的深度。

为了我们的应用程序便于扩展和维护，我们应该定义各个分离层。毕竟我们还不知道以后会加入什么逻辑，是从数据库检索数据？还是从Web Service获取？所以我们必须重做整个视图。

MVP模式使得视图独立于我们的数据源，我们可将应用程序划分为至少三个不用的层次，便于我们能够独立测试他们。采用MVP模式我们可以把大部分的逻辑从Activity中分离出来，使得我们可以不用借助单元测试（instrumentation）来单独测试它。

如何把MVP应用到Android？

一切问题开始变得更加分散，有点复杂了。实现MVP的方式有很多种，我们每个人都可以根据自己的需求和自己喜欢的方式去修改MVP的实现方式，它可以随着Presenter的复杂程度变化。比如在View中需不需要控制进度条？或者是在Presenter层处理？谁来决定Action Bar该显示什么操作？这是一个艰难的决定。这里我会展示我自己的做法，但是我希望本文成为一个讨论如何应用MVP的地方，因为目前为止还没有实现MVP的标准方式。

Presenter
Presenter主要作为沟通View和Model之间的纽带，它从Model层取数据，返回给View层，但它不像典型的MVC结构，因为它也可以决定与View层的交互操作。

View
View通常来说是由Activity实现的（或者是Fragment，View，这取决于app的整体结构），它会包含一个Presenter的引用，最理想的Presenter是由一个依赖注入管理器提供，比如Dagger，不过如果不用依赖注入管理器的话，就需要独立创建Presenter对象了。View要做的事情就仅仅是在每次有接口调用的时候（比如按钮点击后）调用Presenter提供的方法。

Model
对于一个结构化的APP来说，Model主要是通向主领域层或者逻辑层的入口，如果使用了Uncle Bob clean architecture的话，Model就可能是一个实现了用例场景的交互工具，这也是我将要在另一篇文章中讨论的一个主题。现在，只要把它看做是给View提供数据的容器就可以了。

例子
鉴于已经解释的太长了，本人写了一个例子an MVP example on Github ，包含一个登录界面，可以验证数据然后进入一个带有列表的主界面，数据来自Model，因为这个例子比较简单，所以本文就不讲解代码了，但是如果读者觉得还是很难理解的话，我还可以再写一篇文章详细介绍。

总结
在Android上要分离接口和逻辑其实不容易实现，但是Model-View-Presenter模式可以更轻易的防止在大的项目中的Activity中掺杂太多的代码，组织好代码结构是开发的最基本的要求，否则，想实现代码的稳定性和可扩展性就很麻烦了了。

原文：MVP for Android: how to organize the presentation layer

另附：Android框架模式之MVC与MVP