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

前言：

如果你的基础牢固，那么你就可以高高在上，触手可及。

Android 框架不提倡任何特定的方式来设计您的应用程序。在某种程度上，这让我们同时变得更加强大和脆弱。

为什么我甚至会想到这个，当我被提供了 Activity 并且我可以使用很少的 Activity 来编写我的整个实现？

多年来，通过 Android系统编写代码，我意识到在某个时间点上解决问题或实现功能是不够的。相信您的应用程序也经历了许多更改周期和功能添加/删除。如果没有正确设计关注点分离，那么在一段时间内合并这些会在您的应用程序中造成严重破坏。这就是为什么我从我为应用程序编写的非常单一的代码中提出了一个我虔诚地遵循的指南，来用于我的所有架构设计。

MVP 哲学中提出的原则是迄今为止我遇到的最好的原则。

什么是 MVP，我们为什么要探索它呢？

让我们回到过去。我们大多数人开始都是创建一个以 Activity 为中心的 Android 应用程序，并且能够决定要做什么以及如何获取数据。活动代码在一段时间内开始增长并成为不可重用组件的集合。然后我们就开始打包这些组件，Activity 可以通过这些组件的暴露 apis使用它们。我们开始感到自豪，并开始尽可能地将代码分解成碎片。然后我们发现自己置身于难以追踪依赖和使用的组件海洋中。此外，我们后来介绍了可测试性的概念，并发现如果用测试编写回归会更安全。我们觉得我们在上面的过程中开发的杂乱代码与Android apis耦合非常紧密，阻止我们进行 JVM 测试，也阻碍了测试用例的简单设计。这是以 Activity 或 Fragment 作为控制器的经典 MVC。

因此，我们制定了一些原则，如果仔细实施，可以解决上述大部分问题。这些原则，我们称之为 MVP（Model-View-Presenter）设计模式。

什么是 MVP 设计模式？

MVP 设计模式是一组准则，如果遵循这些准则，可以将代码解耦以实现可重用性和可测试性。它根据其角色划分应用程序组件，称为关注点分离。MVP 将应用程序分为三个基本组件：

1. 模型：它负责处理应用程序的数据部分。
2. View：负责在屏幕上布置带有特定数据的视图。
3. Presenter：它是连接模型和视图的桥梁。它还充当 View 的指导者。

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

1. View 的唯一职责是按照 Presenter 的指示绘制 UI。它是应用程序的一个愚蠢部分。
2. View 将所有用户交互委托给它的 Presenter。
3. 视图从不直接与模型通信。
4. Presenter 负责将 View 的需求委托给 Model，并通过针对特定事件的操作来指示 View。
5. 模型负责从服务器、数据库和文件系统中获取数据。

上述原则可以通过多种方式实现。每个开发人员都有自己的愿景。但简而言之，基本的螺母和螺栓很常见，只需稍作修改。

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

现在，我放下序言，我跟随MVP。

1. Activity、Fragment 和 CustomView 充当应用程序的 View 部分。
2. 每个视图都有一个一对一关系的 Presenter。
3. View 通过接口与其 Presenter 进行通信，反之亦然。
4. 该模型分为几个部分：ApiHelper、PreferenceHelper、DatabaseHelper 和 FileHelper。这些都是 DataManager 的助手，它本质上绑定了所有模型部件。
5. Presenter 通过接口与 DataManager 进行通信。
6. DataManager 仅在被询问时提供服务。
7. Presenter 无权访问任何 Android 的 apis。

现在，所有这些信息都可以在任何博客或 MVP 的 Android 指南中找到。那么这篇文章的意义何在？

写这篇文章的原因是为了解决一个非常重要的 MVP 挑战。 如何将它作为一个完整的应用程序来实际实现？

用一个简单的 Activity 示例来解释 MVP 似乎很简单，但当我们尝试将应用程序的所有组件绑定在一起时，这就会让我们感到迷茫。

如果您想深入了解美丽的编码世界并为之着迷，请阅读本文。这不是一篇新闻文章，所以要参与其中，穿上鞋子后背挺直，远离所有干扰。

让我们先勾勒一下架构的蓝图。

对于任何软件，架构是你应该首先要做的事情。精心设计的架构将最大限度地减少未来的大量返工，同时提供可扩展性。今天的大部分项目都是在一个团队中开发的，因此代码可读性和模块化应该被视为架构中最重要的元素。我们还严重依赖第三方库，并且由于用例、错误或支持，我们不断在替代方案之间切换。因此，我们的架构应该采用即插即用设计。类的接口用于此目的。

上面绘制的 Android 架构蓝图包含所有这些特性，并且基于 MVP 原则。

下面的内容一开始可能会让人感到不知所措，但是当您通过本文下一部分中的一个active 示例时，概念对您来说将变得显而易见。

知识来自于那些渴望得到它的人的身上。

让我们了解草图架构的每个部分。

• 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 的操作委托。

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

• 应用程序类通过传递 DbHelper、PreferenceHelper 和 ApiHelper 引用来实例化 AppDbHelper（到 DbHelper 变量）、AppPreferenceHelper（到 PreferenceHelper 变量中）、AppApiHelper（到 ApiHelper 变量中）和最后的 AppDataManager（到 DataManager 变量中）。
• View 组件通过 MvpPresenter 引用实例化它的 Presenter。
• Presenter 接收它的 View 组件并通过 MvpView 引用它。Presenter 也接收 DataManager。
• DataManager 作为单例实例存在。

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

作者:Janishar Ali
链接：https://blog.mindorks.com/essen