iOS的VIPER架构，谁拥有实例化一个整体模块？ [英] iOS VIPER architecture, who has to instantiate a whole module?
问题描述
考虑到VIPER架构
我有两个模块，A和B.第一模块A，通过presenter，要执行已经在模块B做一个动作，所以道出了线框做到这一点。现在的问题是，谁负责实例化整个模块（视图，交互器，presenter ...）。我看到一些例子用不同的方法：
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的一类方法instantites所有的B模块。
考虑到线框负责路由，它是还负责创建其模块的？
Taking into account that the wireframe is responsible for routing, is it also responsible of creating its module?
推荐答案
TL; DR ：我会建议你应该使用类似的台风并让该句柄实例。
TL;DR: I would recommend you should use a DI framework like Typhoon and let that handle instantiation.
你可能不会希望你的线框在VIPER模块实例的一切（查看，presenter，交互器，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:
- VIPER类的初始化：您能介绍一个工厂，或使用DI工具，其目的是为了解决这个问题
- 操作导航：此停留一
线框的职权范围内 。
- initialization of VIPER classes: you can introduce a factory, or use DI tools which are designed to solve this problem
- doing navigation: this stays within the remit of a
Wireframe.
补充说明
如果你想知道谁实例化下一个模块？，然后再次，恕我直言，我认为这是不对的，有些模块A 的线框会谈模块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.
原因是，模块A 现在会提出，要依赖于模块B ，引起了紧耦合：这违背模块的目的。这个话题在上GitHub上 =]
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屋！
