iOS体系结构模式分析

通过谢尔盖·沙巴林（Sergey Shabalin）

iOS环境中有四种主要的架构模式，而Bohdan Orlov已将它们全部揭开神秘面纱。 我将尝试指出MVC，MVP，MVVM和VIPER之间的主要区别，这些区别可能会在为您的应用程序构建适当的体系结构时发挥作用。

模型-视图-控制器模式

我认为这是一种基本模式，已被证明是多种技术中的有用工具，对它们的开发有所贡献，并且通常是对开发人员的有用助手。 如果您问建筑师什么是实现此模式的最佳方法，则很可能会获得所有不同的版本和解决方案。 所有模式的一个重要特征是UI与编码逻辑的分离，这使设计人员无需考虑代码即可完成工作。

MVC模式的首次出现归因于SmallTalk语言。 它需要一种架构解决方案，该解决方案必须能够将UI元素与域逻辑分离，并将域逻辑与数据分离。 因此，MVC在其原始视图中由构成其名称的三个类别组成。 细目分类有助于我们更好地了解实体，重用它们并单独进行测试。 让我们看一下类别：

• 模型是域数据访问和操纵的类别。 域逻辑。
• 视图是负责图形用户界面元素的类别。 用户界面。
• 控制器是其他两个之间的中间类别。 它根据View中的动作更改Model ，并根据Model的更改调整View 。 实现用例。

通过将实体划分为模式组件，我们可以定义它们对良好体系结构的贡献，该体系结构具有均衡的负载分配，易于测试以及维护成本低廉的特征。

该模式背后的主要思想是Controller和View依赖于Model，但是Model不依赖于它们。 这使得无论视图和控制器如何，都可以开发和测试模型。 最好的情况是Controller不处理View，并且View可能有多个Controller之间切换。 同样，Controller可以用于多个视图。 例如，一个Controller可能取决于用户登录。用户看到视图并创建一些输入数据，这些数据在从Model订阅通知时被传输到Controller。 视图从模型接收更新，并向用户呈现其最后状态。

模型视图展示者模式

此模式还包括三个组件。 下图说明了视图不必订阅模型更新，控制器（现在为Presenter）将更新通知给视图。 这种方法允许创建抽象视图。 MVP模式的实现可以通过分解View接口来完成。 然后，每个视图将具有其呈现者需要的某些方法和属性集的接口。 该接口由Presenter初始化，Presenter订阅View事件通知并在必要时提交数据。 这种方法允许在应用程序开发中使用TDD（测试驱动开发）方法。

Model-View-ViewModel模式

乍一看，这种MVVM和MVP模式的实现看起来非常简单且相似。 但是，对于MVVM，View to ViewModel连接是自动的，而MVP需要为此执行一些编程操作。 看来MVC拥有更多的View控制机会。

VIPER模式

最后一位提名人特别有趣，因为它不属于MV（X）类别。 在这一点上，我相信您同意分工是一件好事。 VIPER朝着这种分离迈出了又一步，提供了五层而不是通常的三层。

• Interactor包含连接到Entities的域逻辑，例如，创建新实体实例或从服务器中检索它们。 为此，您最好使用某些服务和管理器，这些服务和管理器更像是外部依赖项，而不是VIPER模块的一部分。
• Presenter包含附加到UI的域逻辑，并在Interactor上调出方法。
• 实体是简单的数据对象，与与Interactor负责的数据访问层无关。
• 路由器管理VIPER模块之间的转换。

实际上，VIPER模块可以是您应用的屏幕或整个用户故事。 例如，身份验证过程可以使用一个屏幕或几个连续屏幕。 由您自己确定模块的最佳尺寸。

这些是VIPER和类似MV（X）的模式之间职责差异的核心分离：

1.基于模型的逻辑转移到交互器级别。

2. 实体是保持空闲状态的数据结构。

3. Presenter不会更改数据，但已将Controller / Presenter / ViewModel UI表示职责迁移到其中。

VIPER是解决导航问题的第一个模板，它利用了Router 。