设计Android应用程序架构的基本指南：MVP：第1部分

原文链接：https://blog.mindorks.com/essential-guide-for-designing-your-android-app-architecture-mvp-part-1-74efaf1cda40#.lkml1yggq   翻译有不合理的的地方，欢迎指出

如果你的基础坚固，那你可以升得更高摸到天空。——万丈高楼平地起 (译者理解的意思)

Android框架并没有提倡任何特定的方式来设计应用程序。这在某种程度上使我们变得更强大也更脆弱。在Android提供给我Activity并且实际上我可以用少量Acitivities来实现应用的功能的情况下，为什么我还会这么认为呢？在写了多年Android代码的过程中，我意识到仅仅去解决某一个问题或实现某一项功能是不够的。你的应用会经历很多迭代和功能增删。如果不在设计时遵循关注点分离(separation of concern)原则，经过一段时间的积累，这些会对你的应用造成严重的破坏。这就是我提出了这个我会在我设计程序结构时一直严格遵循的指南的原因。

MVP理念中提出的原则是迄今为止我遇到过的最好的原则。

什么是MVP，我们为什么要探索它？让我们先来回顾一下。我们大多数人写Android 应用时，会先从Activity开始，以Activity为中心，并有它来控制逻辑以及如何数据。经过一段时间Activity的代码不断增长，变成一个包含大量不可复用的功能组件的集合。然后我们开始抽离这些组件，再将功能接口提供给Activity使用。我们开始尽可能地将代码分解成碎片。然后我们发现自己处于功能组件的海洋中，这些组件难以追踪依赖关系和使用。此外，我们随后了解到可测试性的概念，并发现结合测试模块编写的回调会更安全。我们觉得我们在上面的过程中开发的混乱代码与Android apis高度耦合，阻碍我们进行JVM测试，也阻碍了测试用例的简单设计。这是使用Activity或Fragment充当控制器的经典MVC模式。因此，我们制定的一些如果严格遵守可以解决大多数上述问题的原则。这些原则，我们称之为MVP（Model-View-Presenter）设计模式。什么是MVP设计模式？MVP设计模式是一系列的准则，如果遵循这些准则，代码将解耦并提高可复用性和可测试性。它根据角色来划分应用程序组件，我们称之为关注点分离(separation of concern)。MVP将应用程序划分为三个基本组件：

1. 模型(Model）：它负责处理应用程序的数据部分。
2. 视图(View)：它负责在屏幕上显示具有特定数据的视图。
3. 主持者(Presenter)：它是连接模型和视图的桥梁。它还充当View的指示者。

MVP为上述组件提供了一些基本规则，如下所示：

1. View的唯一责任是按照Presenter的指示绘制UI。这是程序里一个无脑的部分(译者注：意思应该是View只需要听指挥绘制就好了)。
2. View将所有用户交互委派给其Presenter。
3. View永远不会直接与Model通信。
4. Presenter负责将View的要求委派给Model，并指示View对特定事件的操作。
5. Model负责从服务器，数据库和文件系统中获取数据。

上述原理可以以多种方式实现。每个开发人员都有自己的看法。但简而言之，基本的螺母和螺栓很常见，只需稍加修改即可。

拥有权利的同时也被赋予了重大的责任。

现在，我放弃以前的方式，开始遵循MVP。

1. Activity，Fragment和自定义View充当应用程序的View部分。
2. 每个View都有一对一关系的Presenter。
3. View通过接口与其Presenter通信，反之亦然。
4. 模型分为几个部分：ApiHelper，PreferenceHelper，DatabaseHelper和FileHelper。这些都是DataManager的帮助程序，DataManager实际上绑定了所有Model部件。
5. Presenter通过接口与DataManager通信。
6. DataManager仅在被要求时提供服务。
7. Presenter没有访问任何Android的api的权限。

现在，显然可以的各种MVP相关博客或Android指南中找到上面这些信息。那么这篇文章有什么意义呢？

撰写本文的原因是为了解决MVP的一个非常重要的挑战。如何实际在整个应用程序设计中实现MVP？

当使用单一的Activity进行示例时，MVP看起来非常简单，但当我们尝试将应用程序的所有组件结合在一起时，我们会感到无从下手。

如果你想深入了解并爱上一个美丽优雅的编码世界，那么请继续阅读本文。这不是一篇新闻文章，所以请正襟危坐，摒除杂念，专心阅读。

首先让我们勾勒出程序架构的蓝图。

架构是你应该设计任何软件要考虑的第一件事。精心设计的架构将最大限度地减少未来返工量，同时提供易扩展性。如今的大多数项目都是在一个团队中开发的，因此代码的可读性和模块性应该被视为架构中最重要的元素。我们也非常依赖第三方库，并且由于用例，bugs或支持，我们不断在备选方案之间切换。因此，我们的架构应该采用即插即用的设计。类的接口就是为此而设计的。上面绘制的Android架构的蓝图包含所有这些功能，并且基于MVP的原理。

以下内容最初可能会让人感到压力，但是当您在本文的下一部分中看到一个灵活的示例时，概念将变得显而易见。

知识属于那些渴望它的人。

让我们理解一下上面绘制的架构的各个部分。

• View：应用程序的一部分，负责呈现UI和与用户交互。Activity，Fragment和CustomView构成了这一部分。
• MvpView：它是一个由View实现的接口。它包含了暴露给其Presenter进行通信的方法。
• Presenter：它是View的决策对象，是一个纯java类，不访问任何Android API。它接收从其View传递的用户交互，然后根据业务逻辑做出决策，最后指示View执行特定操作。它还与DataManager通信，以获取执行业务逻辑所需的任何数据。
• MvpPresenter：它是一个由Presenter实现的接口。它包含暴露给其通信视图的方法。
• AppDbHelper：数据库管理和与数据库相关的所有数据处理都在应用程序的这一部分完成。
• DbHelper：它是由AppDbHelper实现的接口，包含暴露给应用程序组件的方法。该层解耦DbHelper的任何特定实现，因此使AppDbHelper成为即插即用单元。
• AppPreferenceHelper：它类似于AppDbHelper，但是它被赋予了从android共享首选项读取和写入数据的工作。
• PreferenceHelper：接口就像DbHelper一样，但是由AppPreferenceHelper实现。
• AppApiHelper：它管理网络API调用和API数据处理。
• ApiHelper：它就像DbHelper一样，但是由AppApiHelper实现。
• DataManager：它是由AppDataManager实现的接口。它包含为所有数据处理操作公开的方法。理想情况下，它委派所有Helper类提供的服务。对于此DataManager接口，扩展了DbHelper，PreferenceHelper和ApiHelper接口。
• AppDataManager：它是应用程序中任何数据相关操作的一个联系点。DbHelper，PreferenceHelper和ApiHelper仅适用于DataManager。它委派特定于任何Helper的所有操作。

现在，我们熟悉应用程序中的所有组件及其角色。我们现在将在各种组件中制定通信模式。

• Application类通过传递DbHelper，PreferenceHelper和ApiHelper引用来实例化AppDbHelper（进入DbHelper变量），AppPreferenceHelper（进入PreferenceHelper变量），AppApiHelper（进入ApiHelper变量），最后运行AppDataManager（进入DataManager变量）。
• View组件通过MvpPresenter引用实例化其Presenter。
• Presenter接收它View组件并通过MvpView引用它。Presenter还接收DataManager。
• DataManager作为单例实例存在。

这些是应用程序实现MVP的基本准则。

就像外科医生所教授的所有外科手术程序一样，在他实际执行和实践之前不会有任何用处。在我们实际执行之前，我们将无法理解这些想法和实现。

在下一部分中，我们将探索一个实际工作的应用程序示例，并希望能够很好地理解和掌握这些概念。以下是本文第二部分的链接： 请通过下列方式联系我~Twitter，LinkedIn，Github，Facebook。程序员的狂欢