具有交互器和存储库 + rxjava 的 MVP 2. 在哪里调用 observeOn 和 subscribeOn答案

【问题标题】：MVP with interactor and repository + rxjava 2. Where to call observeOn and subscribeOn具有交互器和存储库 + rxjava 的 MVP 2. 在哪里调用 observeOn 和 subscribeOn
【发布时间】：2019-01-25 20:43:39
【问题描述】：

我有一个基于 MVP + 交互器 + 存储库的 Android 应用程序。从存储库到演示者的所有层都使用反应流（RxJava 2）连接。查看从演示者请求某些内容，演示者从交互者请求，交互者从存储库请求，以及从 API 本身请求存储库。响应通过与从 API 到 Presenter 的反应流相同的层。每一层都可以为底层映射数据。

问题是。我应该在哪里调用 subscribeOn(io()/computation()/etc) 和 observeOn(AndroidSchedulers.mainThread()) ？我认为应该从演示者调用observeOn(AndroidSchedulers.mainThread())，因为可以在交互器中执行繁重的计算。在许多示例中 subscribeOn(io()/computation()/etc) 是从演示者调用的，但我不同意这种方法。我认为演示者不应该决定在哪个线程中加载数据。存储库应决定在哪个线程中从 API 加载数据。例如，如果我们有存储库接口来加载联系人。一个实现可以从数据库或互联网或内存存储中获取数据。无需为内存存储库创建线程。所以仓库应该决定是否订阅 io/computation/etc 调度器。

有什么想法吗？

【问题讨论】：

在我的开放中，多线程的东西与模型和逻辑无关。它们可能因平台而异，因此我在表示层中设置了流的调度程序。
同意@Malv，它与架构无关。通常我会订阅视图并观察演示者中的 api 响应。

标签： android rx-java2 mvp clean-architecture

【解决方案1】：

我不会在存储库层调用subscribeOn() 和observeOn()，原因如下：

隐式在不同线程上执行的方法很难使用，并且可能会导致调用它们的客户端出现问题。
如果您想组合来自不同存储库的多个流，控制它们会更方便。如果它们在不同的线程上订阅，这可能会导致细微的错误、低于最佳性能和难以阅读的代码。
这为 repo 层增加了另一个责任。 repos 现在不是简单的数据存储，而是知道线程。在我看来，这违反了单一责任原则。

我通常在视图之前的最后一层调用subscribeOn() 和observeOn() - 在这种情况下，这将是您的演示者层。在那里，我可以完全控制交互者的组成，并更好地判断我想在哪里处理事物以及我在哪里需要处理结果。

【讨论】：

你能给我一些例子吗？原因是 1 和 2？第三个呢，我同意，但我不确定演示者应该管理线程。
如果我有一个存储库接口的两种实现怎么办？其中之一只是将数据存储在 RAM 中。无需使用单独的线程来写入或读取数据。存储库的另一种实现使用 SQLite。所以它应该使用 i/o 调度程序当我在演示者中使用 subscribeOn 时，我无法预测存储库的哪个实现使用交互器。这就是为什么我认为存储库应该决定选择哪个调度程序。
@Radik 你是对的，交互者不应该关心回购的具体实现。但是想象一下这种情况——您从缓存存储库中获取数据并调用observeOn(AndroidSchedulers.mainThread())。然后你flatMap() 到另一个执行网络请求的流，你最终得到一个NetworkOnMainThreadException。问题不会很明显，也不容易调试。
@Radik 另外，如果 repo 的实现发生变化会发生什么？线程模型也将隐式更改，而不通知客户端，这可能会导致错误。恕我直言，最好有一种使用回购方法的通用方式。从另一个线程调用本地缓存不会导致任何错误，但是在错误的线程上发出网络请求可能会炸毁您的应用程序。让开发人员知道哪种方法适用于哪个线程是不好的。
我绝对应该从演示者那里调用 observeOn(AndroidSchedulers.mainThread())。主要问题是关于在哪里调用 subscribeOn(...)。 AFAIK 如果我从缓存的 repo 流 flatMap 到另一个执行网络请求的流，我不会得到 NetworkOnMainThreadException