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

时间:2017-12-18 12:37:21

标签: android mvp use-case clean-architecture

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

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

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

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

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

  3. 这两种解决方案都存在缺陷,违背了基本原则(DRY,单一责任原则)。

2 个答案:

答案 0 :(得分:4)

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

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

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

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

答案 1 :(得分:0)

MVPC模式可能就是你所追求的。 This是我很久以前写的(尽管代码示例很差,请原谅!)