干净的体系结构:组合交互器 [英] Clean Architecture: Combining Interactors

问题描述

我最近偶然发现了Bob叔叔的干净的体系结构"，我很想知道交互器是否可以执行其他交互器.

I've recently stumbled upon Clean Architecture, by Uncle Bob, and I'm curious to know whether Interactors can execute other Interactors.

例如，这些是我到目前为止的交互器:getEmptyAlbums，getOtherAlbums.两者都具有分别返回专辑列表(专辑模型的ArrayList)的回调.

For example, these are my Interactors as of now: getEmptyAlbums, getOtherAlbums. Both have Callbacks that return with a list of Albums (An ArrayList of an Album model) respectively.

我可以让一个名为getAllAlbums的Interactor在其run块中执行前两个Interactor吗?

Am I allowed to have an Interactor called getAllAlbums that executes the previous two Interactors within it's run block?

@Override
public void run() {
    getEmptyAlbums.execute();       
}

void onEmptyAlbumsReceived(ArrayList<Album albums){
     getOtherAlbums.execute;
}
void onOtherAlbumsReceived(ArrayList<Album albums){
         mMainThread.post(new Runnable() {
         callback.onAlbumsReceived(albums);
     }
});

推荐答案

我一直在思考同一件事，在对该主题进行了很少的研究之后，我得出的结论是是"，这很可能是 最佳选择.

I have been pondering the same thing and after finding very little on the subject, I have come to the conclusion "Yes" it is probably the best option.

我的推理如下:

1. 单一职责:如果您不能汇总用例，那么每个案例都不能真的是单一职责.如果没有聚合，则意味着域逻辑最终会出现在表示层中，从而达不到目的.
2. DRY:用例可以共享，并且应该有意义.

1. Single Responsibility: If you can't aggregate use-cases, then each can't really be single responsibility. Without aggregation, it means domain logic ends up in the presentation layer, defeating the purpose.
2. DRY: use cases can be shared, and should be where it makes sense.

为保留单一职责，我将考虑限制汇总用例仅执行 ，即执行这些用例并进行任何最终转换.

To preserve single responsibility, I would consider limiting aggregating use-cases to do only that, i.e. executing those use cases and doing any final transformations.

鉴于这个问题的年代久远，我想知道您采用哪种方式以及遇到的问题.

Given the age of this question, I'd be interested to know which way you went with this and issues you encountered.

这篇关于干净的体系结构:组合交互器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！