在干净的 MVP 中,谁应该处理组合交互器?

In clean MVP, who should handle combining interactors?

我见过 MVP 架构的好例子 (here and here)。两者都只提供简单的交互器,但我想知道如何处理更复杂的用例,包括在其他用例中重复的步骤。

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

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

  1. 演示者应该链接所有的交互者。只要用例不复杂且没有很多先决条件,此解决方案就有效。在我看来,这不是正确的地方,因为它给主持人增加了另一个责任。

  2. Interactor 可以使用很多存储库(没有干净的体系结构规则被打破)。为什么不在其他交互器中使用 TokenRepository?因为获取令牌比仅仅到达存储库要复杂得多。在其他交互器中重复这些步骤不会重用已经存在的代码。

两种解决方案都有其缺陷并且违反基本原则(DRY,单一职责原则)。

如果我是你,我会把获取令牌的逻辑放在一个单独的交互器(可能命名为 getTokenInteractor)中,然后从可能需要它的其他交互器调用该交互器。 这样,您可以在交互器中选择使用令牌(并调用或不调用您的 getTokenInteractor),也可以在交互器中检索它并处理错误。 我会为您的 "getVersionChanges" 用例做同样的事情,让交互者链接调用。

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

这样,您的业务逻辑可以 100% 留在您的交互器中,您的演示者可以专注于他将如何在屏幕上显示它。

顺便说一下,如果您的 API 每次调用都需要一个令牌,您应该将其移动到拦截器中,这样您就不必在每次调用时都处理它。

MVPC 模式可能就是您所追求的。 This 是我很久以前写的东西(虽然代码示例很差,所以请原谅!)