4

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

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

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

  1. Presenter 应该链接所有的交互者。只要用例不复杂且没有太多先决条件，此解决方案就可以工作。在我看来，这不是正确的地方，因为它让主持人承担了另一项责任。

  2. Interactor 可以使用许多存储库（那时没有破坏干净的架构规则）。为什么不在TokenRepository其他交互器中使用？因为获取令牌比仅仅访问存储库要复杂得多。在其他交互器中重复这些步骤不会重用已经存在的代码。

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

4

2 回答 2

6

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

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

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

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

于 2017-12-18T17:06:54.197 回答
0

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

于 2018-01-24T10:11:50.300 回答