在干净的 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 每次调用都需要一个令牌，您应该将它移动到拦截器中，这样您就不必在每次调用时都处理它。

Answer 2

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