VIPER建筑

在软件开发中，我们遇到许多问题。 难以测试的代码，重复的代码或几乎没有分离的代码几乎每天都会让我头疼。

模式尝试解决某些用例的常见问题。 单例是一个简单的例子。 它解决了一个类只必须具有一个状态的问题。

设计模式（例如单例）和体系结构模式之间的区别在于，体系结构模式解决了与关注点分离相关的问题。

问题

我们创造了惊人的应用程序。 以及出色的应用程序，出色的用户界面和复杂的功能。 这意味着我们的功能将随着它们的增长而变得复杂。

我们必须考虑如何使所有内容清晰，可扩展，可维护且易于理解。

解决方案

VIPER正是解决了这个问题：它描述了我们零件的责任以及它们之间如何相互作用。

我将App PursCreate重构为VIPER，并开始在其他一些较大的项目中使用它。 这就是我学到的：

• 一切都有特定的位置。 您完全知道例如在路由器或演示器中放置了功能。
• 结构变得更加复杂，但是添加新功能并使它们与其他功能分离非常容易
• 我减少了副作用
• 为我的业务逻辑编写UnitTests更容易

让我简要介绍一下VIPER的各个部分：

视图

启动应用程序时，您看到的就是视图。 是带有圆角半径和阴影或某些渐变色药丸的红色按钮。

主持人

表示逻辑处理所有必要的操作，以便在视图中显示所有必需的信息（向数据的交互器询问） 。

它还可以处理所有用户交互，例如显示新屏幕，直观地进入编辑模式或自定义反向操作。

互动者

交互器包含业务逻辑或充当业务逻辑的基础。

在我最近的项目中，常见的用例是CoreData访问，在产品列表（购物应用程序）中过滤产品或触发HTTP请求。

实体

实体代表您的DataModel。 这可能是ManagedObjectModel（用于CoreData）或包含HTTP响应的结构。

路由器

路由器处理所有显示和导航逻辑。 例如，当用户单击一个按钮时：演示者将呼叫路由器并说：displayMyView（）。

为什么要提取这种简单的逻辑？

因为它迅速增长。

在我的App PursCreate中，我遇到以下情况：

单击单元格时，将显示您的目标概述。 有两种目标类型。 因此，您必须确定这是经典任务还是连胜纪录。

现在，用户可以编辑他的目标。 如果他进入编辑模式，则必须再次确定类型，但是这次打开对应任务而不是概览的编辑。

当应用增长时，这部分可能会变得非常复杂。

复杂

VIPER具有许多优势。 但是，它带有很多复杂性。 这可能会导致不必要的过度设计。

作为程序员，我们的工作是确定哪种架构模式适合我们的用例。 也许MVC或MVVM非常适合简单的用例。 在更复杂的情况下，VIPER得益于其分离性和可伸缩性。

本文完美地描述了它。 我强烈建议阅读：

MVVM和VIPER之间的界线模糊-开发人员思想-中