我在这里阅读了有关VIPER架构的http://www.objc.io/issue-13/viper.html（以及其他几个来源），但我仍然无法弄清楚一件事，每个演示者最多只能与一个交互者进行交互吗？
以下是关于它的更长时间的讨论，可以更好地解释我的问题：Use Case with 2 ways for the same action
答案 0 :(得分：6)
我得到它，演示者每个VC都是唯一的。但是，当演示者需要多个交互者时，他可以使用它们。
我认为交互者是一层业务逻辑，他们可以互相交流，演示者可以与其中许多人互动。
但是，将正确的逻辑放在正确的层中非常重要。例如，注意不要将业务逻辑放在presenter层中，因为它必须在几个交互器之间导航时非常诱人。请记住，只将业务逻辑放在交互者中。
答案 1 :(得分：2)
理想情况下，否。一位主持人应该知道只有一个Interactor的存在。但是，交互器本身可以拥有许多数据管理器。我通常使用至少两个数据管理员：一个用于API请求，另一个用于本地数据管理。
有关VIPER架构的更多高级技巧和有用的良好做法，我推荐这篇文章：https://www.ckl.io/blog/best-practices-viper-architecture（包括示例项目）
答案 2 :(得分：0)
不理想，正如马塞洛指出的那样。但是，我觉得为数据管理者在VIPER中添加“ D”也不是很理想。
VIPER中的一个大问题是，演示者在从视图中接收到输入后就已经知道哪个用例可以触发，因此，它已经对业务用例有了一些先验知识。在我看来，这个事实本身就对整个体系结构提出了质疑，因为如果演示者仅将与用例无关的视图或纯粹的UI事件通知给交互者，则对于现有的对象将毫无用处。 VIPER的演示者无论如何都必须具有一点“业务逻辑”。
因此，由于演示者已经必须通过与交互者交谈来协调用例，因此每个业务用例只有一个交互者，如果每个“模块”中有多个业务用例，则演示者可以将它们连接起来。如果没有变通办法，VIPER中的边界通常很难在实践中维护，但这是一个很好的体系结构，可迫使开发人员考虑关注点的分离。
答案 3 :(得分：0)
根据CheeseCake Best Pratices，连接多个VIPER模块的唯一方法应该是使用路由器层。这样，如果删除任何模块，则在其他相关模块中会出现错误的唯一层将是路由器。另外，为避免耦合，可以将实体放置在专用于此目的的单独模块中。最后，为减少代码重复，将相似的实体（例如，用户和个人资料）分组到相同的数据管理器中。
答案 4 :(得分：0)
聚会有点晚了，但我只是在谷歌上搜索了这个问题以寻找其他东西。
这实际上取决于您对 VIPER 的实施。没有唯一正确的方法，据我所见，人们以非常不同的方式实施它，应该对其进行调整以满足您的特定需求。
有些项目每个视图都有紧密耦合的交互器，其中视图显示数据，展示器在视图和交互器之间传递数据（在过程中转换它），交互器处理每个视图的业务逻辑。在这种情况下，演示者将只与一个交互者交谈。
其他项目根据用例实现交互器，或者换句话说，“次要”功能。这样您就可以避免在模块之间复制业务逻辑。演示者可以在这里与多个交互者交谈。
还有一些项目根据“大”功能或应用程序的每个区域实现了大交互器。这样，交互者往往非常庞大，但也确实成为负责应用业务逻辑决策的“智能”层，他们往往可以访问做出这些决策所需的一切。
让我们在这里举一个例子 - 假设您在应用程序的侧边菜单和设置中有一个注销按钮，并且在注销时您需要清除数据库、钥匙串、用户默认值和网络会话.一个比较常见的场景。
在第一种情况下，每个视图都有一个交互者，显然您有重复的业务逻辑。我相信这就是“原始”VIPER 的工作方式，但这可能不是最好的方法。
在第二种情况下，您可能需要一个“用户会话交互器”来处理用户的登录和注销。
在第三种情况下，您将拥有一个“用户交互器”，不仅可以处理会话，还可以保存和管理所有用户数据。
我通常的方法是第三种选择，它的最大缺点是需要将交互器拆分为多个文件。许多人使用第二个选项。也有可能对于您的项目来说，第一个选项是最好的 - 例如，如果您项目中的屏幕之间几乎没有重叠并且它们与功能紧密对齐。