选择移动架构的重要性

介绍

多年以来，移动应用程序的开发并没有在良好体系结构的设计上大放异彩。 可能是由于移动应用程序（主要针对有限的设备，例如PalmOS增强型设备或WindowsCE），并且由于这些设备的功能和程序如此有限，因此它们运行在很简单的地方，就像史蒂夫·乔布斯所称的“玩具应用程序”一样，需求很高，并专注于正确地构建应用程序架构。 那是用于银行系统或大型应用程序，而不是用于移动应用程序。

现在，情况发生了巨大变化。 我们希望从移动应用程序中获得比以往更多的方式：我们使用几次聊天，发送各种消息，共享和捕获图像和视频，还编辑音频和视频，所有这些都在“简单”的小手机中进行。

也许移动应用程序不是完全成熟的桌面应用程序（也不是必需的），但是它们现在能够执行许多有趣的事情，因此开发此应用程序已成为越来越复杂的任务。

几年前，我在一家大公司工作，在那里，我们开发的应用程序之一（最初是一个简单的POC）最终成为了实际产品。 设计完全是一团糟：没有对象或交互的感觉，没有界面，也没有设计或体系结构。 启动它的人甚至都不了解最基本的iOS编程知识。 当然，此应用程序非常容易出错，添加功能确实是一项艰巨的任务。 没有人想碰它。

“要使用最小化工作量并最大化生产率的设计和架构来构建系统，您需要知道系统架构的哪个属性可以达到这个目的”

所以..我们做了什么？ 好吧，我们要做的第一件事是开始弄清楚应用程序必须做什么，并开始确定必须创建哪些组件，并开始考虑它们之间的交互。

最后，过程大致上是这样的：1）创建一个POC，以实际查看应用程序是否可以执行客户期望的操作2）找到更好的组织应用程序组件并创建出色设计的方法允许对该软件进行单元测试3）实现此设计。

一些有趣的设计模式：

很高兴为我们完成了许多此类工作。 反复发现相同问题的非常聪明的开发人员提出了几个“设计模式”的思想，它们基本上解决了我们可能遇到的一些问题，这是： 设计一个面向UI的应用程序，该应用程序可以具有相互交互的单独层。一种使更改变得简单并具有整套单元测试的好处的方法。

MVC：模型-视图-控制器

MVC是一个非常有趣的移动体系结构。 它是1970年代由Palo Alto Research开发的第一个MV *体系结构，迄今为止，它是许多移动开发平台和许多Web开发框架中的核心体系结构。 今天，Apple将这种体系结构用作其示例和所显示代码的主要体系结构。 这种架构的思想是将视图与控制器分离，将模型与控制器分离。

• 视图 ：视图负责向用户呈现UI元素，以及用户输入和中间件之间的交互。 视图对象知道如何显示，并且可能允许用户编辑应用程序模型中的数据。 该视图不应负责存储其显示的数据。 （当然，这并不意味着视图从不实际存储其显示的数据。出于性能原因，视图可以缓存数据或执行类似的操作）。
• ViewController ：控制器对象充当应用程序的视图对象及其模型对象之间的中介。 控制器通常负责确保视图可以访问他们需要显示的模型对象，并充当视图了解模型更改的渠道。 控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。
• Model ：这是应用程序用来表示数据并在ViewController和服务之间移动信息的抽象。 模型对象代表特殊的知识和专长。 它们保存应用程序的数据，并定义处理该数据的逻辑。 设计良好的MVC应用程序将其所有重要数据封装在模型对象中。 [1]

MVP：模型视图演示者

该体系结构由Microsoft的Martin Fowler于1997年发明。 该模式基本上包括3个可互操作的层。

“ 模型 ”与MVC或MVVM中的概念相同。 然后，“ Presenter ”是Model与ViewController或View Controllers与服务之间的中间层。 这是我们将要测试的层。 MVC和MVP之间的主要区别在于，视图和控制器被视为一个单独的块（视图）。

• 模型 ：与MVC一样，模型表示我们程序处理的抽象。 这可以是和抽象的实体，例如：用户，销售，产品等。我们从现实世界中用来对程序进行建模的任何抽象。 它可能是来自我们的应用程序正在使用的某些服务器的类型。
• View（+ ViewController） ：ViewController将具有对演示者的引用，并将从用户与UI的任何可能交互中通知演示者。 如果要更改UI / UX中的内容，演示者将不得不要求ViewController更新。 演示者还将在ViewController和服务（网络，数据库等）之间进行中介。
• 演示者 ：演示者是一个抽象实体，其中包含应用程序的业务逻辑，完全不了解实际的服务实现。 MVP模式允许我们将ViewController与Presenter分离，然后再将Presenter与服务分离。

MVVM：模型-视图-视图模型

MVVM是一种非常有趣的设计模式，已广泛用于许多不同的平台，但专门用于移动设备。 MVVM通常与诸如RxSwift之类的绑定框架一起使用，它可以帮助我们将 UI元素绑定到Presenter（这基本上意味着ViewModel对UI的引用实际上是用户看到的最新％100屏幕上）。

REDUX ：

这是最有趣的模式之一，因为Redux可以帮助您测试整个应用程序。 这可以归功于设计中的出色抽象，其中每个动作都源于纯函数，这是一个主要开发输入和输出的函数。

Redux通常使用ReSwift编程库来实现。

组件

• 状态：代表应用程序的状态。 只能有一个，可以分为子状态。
• 动作：这些是描述系统功能的简单对象。 根据情况，这些对象是否可以携带信息。 它们是由View层调度的，目的是更改应用程序的状态。
• 减速器：这是我们开发应用程序主要逻辑的地方。 减速器必须是无副作用的纯函数，并且必须是同步的。 它们是唯一可以为应用程序创建新状态的对象。 给它们一个动作和当前状态，并返回一个新状态。

优点缺点

可悲的是，没有万能的软件开发或软件设计。 这也不是。 选择一个复杂的设计模式（例如上面介绍的那些）可能会产生巨大的样板，因此您必须明智地选择它们。

MVC趋向于成为Massive View Controller ，其中大多数代码都在Controller内部，通常会导致产生类似于上帝的类来处理所有内容，并导致代码无法测试。 在尝试其他方法之前，还可以在MVC应用程序中应用几个概念。

每个架构的应用列表

MVVM：

• Microsoft LookGlass（https://softwareengineering.stackexchange.com/questions/37981/who-is-using-the-mvvm-architecture-for-large-applications）

MVP：

• 尚未找到任何出色的示例：

Redux：[2]

• https://www.craftsy.com/apps
• https://www.grailed.com/
• https://www.blinkhealth.com/

结论

重要的是要知道，使用MVVM，MVP等并不是解决使用不良MVC的良方。 我建议在进入更复杂的模式之前，您应该了解它们全部都在MVC中。 有许多架构思想可以应用于MVC。 行业中似乎有一种趋势认为MVC不好，应该避免，但是我会说这是错误的。 如果使用正确，这种简单的设计模式将有很多帮助。

MVVM对于某些项目可能会导致非常大的开销。 MVVM的大多数实现对于每个View或用例至少包含3个类，在某些应用程序中，尽管MVC相当可测试，但在某些情况下，MVC可能足以胜任这项工作，这可能有点过多。 同样，大多数实现可能需要库才能实现，并且可能会增加项目的额外复杂性，从而导致维护代码更加困难。

MVP与MVVM可能存在一些相同的问题：每个实现至少3个类。 我们将在此博客中发布有关如何实现一些最有趣的设计模式的文章，希望我们的读者喜欢这篇文章并给我们反馈。

有任何问题，建议或意见吗？ 您可以在Twitter上对我进行罚款。