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

Question

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

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

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

1. Presenter应链接所有互动者。只要用例不复杂并且没有许多前提条件，该解决方案就可以正常工作。在我看来，这不是正确的地方，因为它给主持人带来了另一种责任。

2. 交互者可以使用许多存储库（当时没有破坏干净的体系结构规则）。为什么不在其他交互者中使用TokenRepository？因为获取令牌比仅仅到达存储库要复杂得多。重复其他交互器中的步骤不会重用已有的代码。

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

Answer 1

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

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

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

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

Answer 2

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