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

Z时代
2024-01-10
分类：问答

我见过MVP架构的好例子（here和here）。两者都只呈现简单的交互器，但我想知道如何处理更复杂的用例，其中包含步骤，这些步骤在其他用例中重复出现。在干净的MVP中，谁应该处理组合交互者？

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

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

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

交互器可以使用许多库（没有干净的建筑规则被打破，然后）。为什么不在其他交互器中使用TokenRepository？因为获取令牌要比到达存储库复杂得多。重复其他交互器中的步骤不会重复使用已有的代码。

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

回答：

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

让我们想象一下，你有一个主持人谁需要显示的版本变化。他将调用第一个交互器（GetVersionChangesInteractor），他将首先检查他是否有一个令牌（通过调用getTokenInteractor），然后调用GetLastLoginDateRepository检索日期，并在该日期调用GetVersionChangesRepository并最终将结果提供给演示者。

这样一来，你的业务逻辑可以在交互件费的100％，你的演示者可以专注他怎么会显示在屏幕上。

顺便说一句，如果你的API需要一个令牌每叫你应该在一个拦截器将其移动，所以你不必在每次调用来对付它。