iOS VIPER 架构，谁来实例化整个模块? [英] iOS VIPER architecture, who has to instantiate a whole module?

问题描述

考虑到VIPER结构

我有两个模块，A 和 B.第一个模块 A，通过演示者，想要执行一个必须在模块 B 中完成的操作，所以告诉它的线框去做.问题是，谁负责实例化整个模块(视图、交互者、演示者...).我看到了一些不同方法的例子:

I have two modules, A and B. The first module A, via presenter, wants to perform an action that has to be done in the module B, so tells its wireframe to do it. The question is, who is responsible of instantiate the whole module (view, interactor, presenter...). I saw some examples with different approaches:

• 在应用开始时创建所有模块.
• 在模块的线框中创建整个模块，因此在本例中，BWireframe 的一个类方法实例化了所有 B 模块.

考虑到线框负责路由，它是否也负责创建它的模块?

Taking into account that the wireframe is responsible for routing, is it also responsible of creating its module?

推荐答案

TL;DR:我建议你应该使用像 Typhoon 并让它处理实例化.

TL;DR: I would recommend you should use a DI framework like Typhoon and let that handle instantiation.

您可能不希望线框实例化 VIPER 模块(View、Presenter、Interactor、DataManager)中的所有内容的原因是您将直接为每个组件创建依赖项.

The reason you probably won't want your wireframes instantiating everything in a VIPER modules (View, Presenter, Interactor, DataManager) is that you'll be creating dependencies directly to each of those components.

依赖使软件抗拒改变:如果我们用我们的洋葱架构来考虑它/六边形架构帽子，线框将跨越至少两个独立的洋葱层的边界通过了解不仅视图，但数据管理器.

Dependencies make software resistant to change: if we think of it with our onion architecture / hexagonal architecture hats on, the wireframe would cross the boundaries of at least two separate layers of your onion by knowing about not only the view, but the data manager.

这迫使我们将线框视为通用基础设施类:即，位于应用程序最外层的东西.

This forces us to treat wireframes as a generic infrastructure class: i.e., something on the outer-most layer of your application.

然而，这与线框的另一个(也是更真实的)职责相矛盾:进行导航.虽然这仍然是基础设施层，但它确实属于 UIKit(-presentViewController: 等).

However, this contradicts with the wireframe's other (and the more real) responsibility: doing navigation. While this is still the infrastructure layer, it belongs firmly and specifically in UIKit (-presentViewController: etc.).

恕我直言，VIPER 的线框图做得太多了.

So IMHO, VIPER's wireframe is doing too much.

唯一明智的做法是将两个职责分开:

The only sensible thing is to split the two responsibilities:

1. VIPER 类的初始化:您可以引入工厂，或使用旨在解决此问题的 DI 工具
2. 进行导航:这属于线框的职责范围.

1. initialization of VIPER classes: you can introduce a factory, or use DI tools which are designed to solve this problem
2. doing navigation: this stays within the remit of a Wireframe.

附加说明

如果您想知道谁实例化下一个模块?"那么，恕我直言，我认为某些 Module A 的线框对话是不对的Module B 的线框图，尽管 VIPER 帖子 说了些什么.

If you're wondering "who instantiates the next module?", then again, IMHO, I think it's not right that some Module A's wireframe talks to Module B's wireframe despite what the VIPER post says.

原因是 Module A 现在将依赖于 Module B，导致紧耦合:这违背了模块的目的.在 Gi​​tHub 上的 VIPER-TODO 项目 =]

The reason is that Module A would now be made to depend on Module B, causing a tight coupling: this defeats the purpose of modules. Much more discussion about this topic over at VIPER-TODO project at GitHub =]

希望这会有所帮助.

这篇关于iOS VIPER 架构，谁来实例化整个模块?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！