Android上的Model View Presenter简介

在开发复杂的应用程序时，通常会遇到以前可能已经解决的挑战，并且已经有了一些非常好的解决方案。 这种解决方案通常称为模式。 我们通常谈论设计模式和建筑模式 。 它们简化了开发，我们应该在适当的时候使用它们。

本教程应帮助您了解设计良好的项目的重要性，以及为什么Android的标准体系结构并不总是足够的。 我们讨论了在开发Android应用程序时可能会遇到的一些潜在问题，并且向您展示了如何通过“ 模型视图展示器” （MVP）模式改善应用程序的可测试性和可靠性来解决这些问题。

在本教程中，我们探索：

• 在软件项目中应用已知架构模式的价值
• 为什么更改Android的标准架构可能是个好主意
• Model View Presenter（MVP）模式背后的关键概念
• MVC和MVP之间的区别
• MVP如何适合Android SDK

在本教程的第一部分中，我们重点介绍MVP模式的理论。 本教程的第二部分更加动手。

1. Android架构

从一开始就应该考虑项目的设计。 我们应该考虑的第一件事是我们计划采用的体系结构，因为它将定义应用程序中不同元素之间的相互关系。 它还将建立一些基本规则以在开发过程中指导我们。

通常，框架或SDK期望事情以某种方式完成，但这并不总是适合项目。 有时，没有预定义或正确的处理方式，将设计决策留给开发人员。 Android SDK期望事情以某种方式完成，但这并不总是足够的，也不是最佳的选择。

尽管Android提供了出色的SDK，但其架构模式却很不寻常，在开发过程中很容易受到干扰，特别是在构建需要长期测试和维护的复杂应用程序时。 幸运的是，我们可以从多种体系结构解决方案中进行选择来解决此问题。

问题是什么？

这是一个棘手的问题。 有人可能会说Android提供的架构没有任何问题。 当然，它可以完成工作。 但是我们可以做得更好吗？ 我坚信我们可以。

Android提供的具有布局，活动和数据结构的工具似乎将我们引向了模型视图控制器 （MVC）模式的方向。 MVC是一种牢固的既定模式，旨在隔离应用程序的不同角色。 这称为关注点分离 。

该体系结构创建了三层：

• 模型
• 视图
• 控制者

每层负责应用程序的一个方面。 Model响应业务逻辑 ， View是用户界面， Controller调解View对Model的访问。

但是，如果我们仔细分析Android的体系结构，尤其是View （活动，片段等）与Model（数据结构）之间的关系，我们可以得出结论，不能将其视为MVC。 它与MVC完全不同，并且遵循自己的规则。 当您的目标是创建可能的最佳应用程序时，它肯定会妨碍您。

更具体地说，如果我们考虑加载程序与“活动”或“片段”之间的共生关系，您可以理解为什么我们应该密切关注Android的体系结构。 一个Activity或Fragment负责调用Loader，后者应获取数据并将其返回给其父级。 它的存在与父对象完全相关，并且视图角色（活动/片段）与加载程序执行的业务逻辑之间没有分隔。

如果单元测试的本质是测试最小的代码片段，那么在数据（装入程序）与视图（活动性或片段）紧密耦合的应用程序中，我们如何使用单元测试 ？ 如果您在团队中工作，并且需要在他人的代码中进行更改，那么如果项目不遵循已知的架构模式并且任何内容都可能存在于任何地方，那么如何找到问题？

解决办法是什么？

我们可以通过实现不同的架构模式来解决此问题，幸运的是，Android SDK允许我们在多个解决方案之间进行选择。 我们可以将选择范围缩小到最适合Android的解决方案。 Model View Controller（MVC）模式是一个不错的选择，但更好的选择是密切相关的Model View Presenter（MVP）模式。 MVP是在与MVC相同的前提下开发的，但具有更现代的范例，可创建更好的关注点分离并最大化应用程序的可测试性。

考虑到Android的体系结构（或缺乏Android体系结构），我们可以得出以下结论：

• Android不必过多担心关注点分离
• 最好让Android的体系结构保持原状，因为它可能会在将来导致问题
• 缺乏适当的架构模式可能会使单元测试成为真正的痛苦
• Android允许我们在几种替代架构模式之间进行选择
• Model View Presenter（MVP）是适用于Android的最佳解决方案之一

2. Android上的Model View Presenter

如前所述，关注点分离并不是Android的强项。 幸运的是，“模型视图呈现器”模式大大改善了这一点。 MVP将应用程序分为三层：

• 模型
• 视图
• 主持人

每个人都有其职责，这些层之间的通信由Presenter管理。 演示者充当不同部分之间的调解人。

• 该模型包含应用程序的业务逻辑 。 它控制如何创建，存储和修改数据。
• 视图是一个被动界面，用于显示数据并将用户操作路由到Presenter。
• 主持人充当中间人。 它从模型中检索数据并将其显示在视图中。 它还处理视图转发给它的用户操作。

MVC和MVP之间的差异

Model View Presenter模式基于Model View Controller模式。 由于它们共享多个概念，因此很难区分它们。 演示者和控制器具有相似的作用。 他们负责模型与视图之间的通信。 也就是说，Controller对管理模型和视图的管理不如Presenter严格。

在MVC模式中，视图层有些智能，可以直接从模型中检索数据。 在MVP模式中，视图是完全被动的，演示者始终将数据传递到视图。 MVC中的控制器也可以在多个视图之间共享。 在MVP中，视图和演示者具有一对一的关系，因此，演示者绑定到一个视图。

• 在MVP中，视图无法访问模型。
• 演示者绑定到单个视图。
• 在MVP模式中，视图完全是被动的。

这些概念上的差异使得MVP模式可以确保更好的关注点分离，并且通过促进三个核心层的更大分离，还可以大大提高应用程序的可测试性。

活动，片段和视图对象

关于如何在Android上实现MVP，有几种解释。 但是，一般而言，活动和片段被分配了视图的角色，并负责创建Presenter和Model。 视图还负责在配置更改之间维护模型和演示者，并通知他们有关视图最终被破坏的信息。

其他View对象（例如RecyclerView）也可以视为MVP中View层的一部分。 视图和演示者之间存在一对一的关系，有时复杂的情况可能需要多个演示者。

到目前为止我们所知道的

• 通过使用架构和设计模式，我们可以使开发变得更加轻松和透明。
• Android缺乏结构良好的架构模式。
• 如果不使用既定的设计模式，我们可能会遇到很多困难，特别是与可维护性和可测试性有关的问题。
• Model View Presenter模式增加了关注点的分离并促进了单元测试。
• 演示者调解视图和模型之间的通信。
• 视图显示数据并将用户交互引导到Presenter。
• 该模型负责应用程序的业务逻辑。
• 视图角色主要由活动或片段承担。

结论

在下一个教程中，我们将在Android上实现Model View Presenter模式。 我们测试了在本教程中学到的概念，并进一步探索了模式的复杂性以及这对Android意味着什么。

在本系列的最后，您可以在自己的项目中实现MVP，创建自己的框架或采用其他已知的解决方案。 我希望在下一个教程中见到您。

翻译自: https://code.tutsplus.com/tutorials/an-introduction-to-model-view-presenter-on-android--cms-26162