令人困惑的术语清洁架构中的交互者

Question

根据清洁架构，设计Interactor是包含所有业务逻辑的部分。 Interactor一词对我来说很困惑。在我看来，Interactor喜欢在数据和演示者这两个不同的层之间进行交互。

这是正确的术语吗？ 任何人都可以清楚Interactor的目的吗？它遵循哪种模式？ 如果Interactor不像我看来那么设计模式是什么 层层交互？

Answer 1

Interactor是一种与“业务逻辑”概念无关的设计模式。没有深入细节，Interactor模式是Command模式的扩展;每个“业务逻辑”对象都被视为“黑盒子”，即为客户端执行的简单指令，将调用操作的对象与知道如何执行操作的对象分离。 （请参阅参考书目以获得扩展说明）。

在android环境中有一个简单的“规则”，要求程序员在后台线程中执行长时间的任务，因此交互模式扩展了“命令模式”，增加了一层线程。实现所有这些复杂的东西是为了创建一个“干净的架构”，它需要一个可扩展，可维护且（可以说）可理解的代码。

关于问题..¿层层交互的设计模式是什么？根据具体情况，它可能有不止一个答案。您可以使用简单的接口作为入口点，因此您可以使用适配器模式，或者可能使用Facade模式，或者如果您想要执行更高级的操作，则可以实现事件总线系统。

来源： 设计模式简单解释 - auth Alexander Shvets。第14页（适配器），第32页（命令），第47页（门面）

Answer 2

如果您熟悉领域驱动设计，则可以将交互器比作应用服务。此外，说“根据干净的架构，设计交互器是包含所有业务逻辑的一部分。”相反，实体将包含业务（应用程序-不可知论）逻辑；而 Interactors 将包含特定于应用程序的逻辑。 交互者将调用实体来完成用例，其中用例可能类似于创建采购订单。

回到使用 Robert Martin（鲍勃叔叔）在其培训视频 Architecture, Use Cases, and High Level Design 中使用的清洁架构术语，鲍勃叔叔说：

<块引用>

交互器是特定于应用程序的。这意味着任何特定于应用程序的业务规则都属于交互器内部。交互者使用特定于应用程序的逻辑来实现他们的目标，该逻辑调用实体内的应用程序不可知逻辑。例如，CreateOrderInteractor 会调用 GetId 的构造函数和 OrderEntity 方法。显然，这两种方法与应用程序无关。交互者知道如何调用这两个方法来实现用例的目标。

您观察到 Interactor 似乎在两个不同的层（如数据和演示者）之间进行交互，该工作实际上属于 Boundary。 Boundary 位于交付机制和 Interactor 之间，其中交付机制可能是桌面应用程序、MVC 应用程序、API 等。这使实际应用程序和业务代码与一个交付分开并可转移机制到另一个。

他还在 Extras 部分有一个很好的图表，显示了购买视频时的交互。它看起来像下面这样：

Delivery Mechanism ==> Boundary ==> Interactor ==> Entity

附言上面引用的视频非常有趣且信息丰富。

Answer 3

从我正在阅读的内容来看，它相当于模型视图展示器（MVP）架构中的Presenter。

它执行业务逻辑，而不是存储或显示数据。它创建一个独立的层，与数据的存储或显示方式或位置无关。它只关心任何格式的输入和输出。它可以在Observer，Adapter和Façade模式的组合中用作回调的接口，代码的通用扩展点，以及分别用于任何非UI或数据存储使用的解耦入口点。

我认为它被称为交互器，因为View与它交互以计算值并刷新任何显示的UI元素，并且它与Model对象交互以提取数据。它也可以与数据库交互以进行CRUD操作，但我认为这主要是在存储库模式中解决的，因为它不是真正的业务逻辑。

Answer 4

Interactors提供了各种用例的实现。理想情况下，每个用例应该有一个交互器，但根据您的应用程序规模可能会有所不同。

现在，为什么对每个应用程序都没有意义呢？假设您有两个应用程序。在第一个应用程序中，您只需要读取一个用户。在另一个应用程序中，您只需更新同一用户。您将有两个不同的交互器，例如GetUserInteractor和UpdateUserInteractor。如果您考虑一下，UpdateUserInteractor对于第一个应用程序将不有意义（反之亦然），对吗？但是，在包含两个服务（读取和更新）的实现的地方（例如，在有关的业务/域对象（或作为单独的用例对象）中），两个应用程序的业务/域逻辑仍然可以相同。这些对象显然可以封装与应用程序无关的业务规则，因为它们可以插入两个或更多不同的应用程序下。

应用程序与用户之间的通信通常是特定于应用程序的。正如其他人已经提到的那样，您可以让交互者对用户操作执行命令。或者，您可以采用另一种类似的方法。但是命令模式确实非常方便，并且可以说使整个代码更加一致，统一和易于理解。

最后但并非最不重要的一点，交互器的另一个重要方面是“边界接口”，它们是多态部署用于输入和输出交付的类。

（PS：例如，在Android中，随着新的体系结构组件，在将输入事件传递到业务逻辑（或域模型）时，片段/活动可被视为输入边界的实现-它是控制器LiveData更像是输出边界实现，因为它在后台使用观察者模式，并通过交互器将数据传递回UI。在这种情况下，我认为这使ViewModel成为交互器的强大候选者，因为它收到了输入事件，还包含LiveData实例。所有这些都很好地分离了，或者是多态部署的吗？好吧，这主要与您的设计有关。

这是我的看法。我希望一切都清楚。

Answer 5

在干净的架构方法中，用例交互器是一个表达特定业务规则的层。用例交互器与实体（不可知的业务规则）交互以实现用例意图。实体可以在其他应用程序中使用，一旦它们是不可知的，另一方面，用例交互器是特定的应用程序对象。

可以在 Clean Architecture 一书的 Robert C. Martin 的第 20 章中找到

Answer 6

这是MVP模式。是的，因为你说它是演示者和数据之间的中介（作为休息呼叫或共享偏好或Sqlite的一种形式）。