在干净的MVP中，谁应该处理组合交互者？

Question

我已经看到了很好的MVP架构示例（here和here）。两者都只呈现简单的交互者，但我想知道如何处理更复杂的用例，包括在其他用例中重复的步骤。

例如，我的API需要令牌来验证任何调用。我创建了一个交互器来获取该令牌（GetToken）。我想获取用户的上次登录日期（GetLastLoginDate），然后获取在该日期和现在（GetVersionChanges）之间发生的更改列表。

那些交互者应该被链接在哪里？我想将它们分开，因为其中一些在代码的其他部分中被重用。我想出了两个解决方案。

1. 演示者应链接所有交互者。只要用例不复杂并且没有很多前提条件，该解决方案就可以正常工作。在我看来，这不是正确的地方，因为它给主持人带来了另一种责任。
2. Interactor可以使用许多存储库（当时没有干净的体系结构规则）。为什么不在其他互动者中使用TokenRepository？因为获取令牌比仅仅到达存储库要复杂得多。重复其他交互器中的步骤不会重用已有的代码。

这两种解决方案都存在缺陷，并且违反了基本原则（DRY，单一责任原则）。

Answer 1

如果我是你，我会把一个令牌的逻辑放在一个单独的交互器（可能名为getTokenInteractor）中，并从你可能需要它的其他交互器调用该交互器。这样，在一个交互器中，您选择使用令牌（和调用或不是您的getTokenInteractor），也可以在您检索它并处理错误的交互器中。我会对你的“getVersionChanges”用例做同样的事情，并让一个交互器链接这些调用。

假设您有一位需要显示版本更改的演示者。他将调用第一个交互器（GetVersionChangesInteractor），他将首先检查是否有令牌（通过调用getTokenInteractor），然后调用GetLastLoginDateRepository来检索日期，并使用该日期调用GetVersionChangesRepository，最后将结果提供给您的演示者。

这样，您的业务逻辑可以在您的交互器中保持100％，并且您的演示者可以专注于他将如何在屏幕上显示该业务逻辑。

顺便说一句，如果你的API需要为每个调用都有一个令牌，你应该在Interceptor中移动它，这样你就不必在每次调用时处理它。

Answer 2

MVPC模式可能就是你所追求的。 This是我很久以前写的东西（虽然代码示例很差，所以请原谅！）