iOS应用程序的清洁架构

VIPER推广了适用于iOS的Clean Architecture。 与Bob叔叔的原作相比，这是一个很小却根本的区别！

在过去的一年中，我非常高兴与业务中的朋友讨论可以在iOS *中使用的各种架构模式。

讨论通常会回到“清洁建筑”一文中的想法。 我们尝试在iOS应用程序的上下文中了解它，以及它如何与平台的其他惯用模式（如模型视图控制器和情节提要）相适应。

一个反复出现的主题是理解“ Presenter ”的“ 正确 ”角色-最具体的示例在使用VIPER架构iOS应用程序中进行了详细介绍。 VIPER作为第一个可行的示例很受欢迎，并且很好地解释了Bob叔叔的适用于iOS的Clean Architecture方法**

与原始资料进行更仔细的比较后，发现在Presenter上，Clean Architecture和VIPER之间存在无法解释的不一致，这似乎是很根本的。

VIPER建筑

通过以下简单说明，我们介绍了Presenter在VIPER中的角色：

演示者：包含视图逻辑，用于准备要显示的内容（从Interactor接收） 和对用户输入做出反应 （通过从Interactor请求新数据）

清洁建筑

在我们将其与原始“清洁架构”文章中的图表进行比较之前，这似乎是合理的。

你看见了吗？ 这条无痛的粉红色小线几乎是在事后想写的！ 继续说明：

这些模型可能只是从控制器传递到用例 ，然后从用例传递到演示者和视图的数据结构。

注意控制流程。 它从控制器开始，遍历用例 ，然后在演示者中结束执行。 另请注意源代码依赖性。 他们每个人都指向用例。

当您看到所有参与者的更详细的时序图时，这可能会变得更加清晰（也许）。

一个方向

VIPER采用传统的堆栈体系结构方法，其中通信是双向的，例如向下流经各层，然后再次进行备份。 在“干净的体系结构 ”中，控制流只能沿一个方向传播。

视图->交互器->演示者->视图

演示者不是View和Interactor之间流程的中央协调者，它的唯一职责是作为接口适配器，将来自Interactor的输入转换为方便的东西，例如View Model跨越边界。

就这样-很小但很重要的变化。 突然，体系结构变得越来越简单。 单一方向上的控制流非常可爱，其好处似乎有几个：

• 关于架构的更容易推理
• 改善关注点分离
• 删除Presenter Interactor之间不必要的样板
• 消除诱惑以拦截通过Presenter的输入
• 更加遵守依赖性规则

如果您使用VIPER，那么您可能已经在项目中看到了Clean Architecture的大部分好处。 更改为“更清洁的体系结构”可能不值得在您的团队中展开辩论。 也就是说，在实现下一个功能时可能值得尝试。