system.reactive - 用响应式(Reactive)编程画线的地方

Question

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便 editing this post用事实和引用来回答。

4年前关闭。



Improve this question





我已经在我的项目中使用RxJava大约一年了。
随着时间的流逝，我变得非常喜欢它-现在我想的可能太多了...

我现在写的大多数方法中都有某种形式的Rx，这太棒了！ （直到不是）。
我现在注意到，某些方法需要大量工作来组合不同的可观察生产方法。
我有一种感觉，尽管我了解我现在写的内容，但是下一个程序员将​​很难理解我的代码。

在开始了解底线之前，让我直接从我在Kotlin中的代码中给出一个示例（不要深入了解它）：

private fun <T : Entity> getCachedEntities(
      getManyFunc: () -> Observable<Timestamped<List<T>>>,
      getFromNetwork: () -> Observable<ListResult<T>>,
      getFunc: (String) -> Observable<Timestamped<T>>,
      insertFunc: (T) -> Unit,
      updateFunc: (T) -> Unit,
      deleteFunc: (String) -> Unit)
      = concat(
      getManyFunc().filter { isNew(it.timestampMillis) }
          .map { ListResult(it.value, "") },
      getFromNetwork().doOnNext {
        syncWithStorage(it.entities, getFunc, insertFunc, updateFunc, deleteFunc)
      }).first()
      .onErrorResumeNext { e ->  // If a network error occurred, return the cached data and the error
        concat(getManyFunc().map { ListResult(it.value, "") }, error(e))
      }

简而言之，它的作用是：


从存储中检索带有时间戳的数据


如果数据不是新数据，请从网络获取数据


再次将网络数据与存储同步（以进行更新）

如果发生网络错误，请再次检索较旧的数据和错误



这是我的实际问题：
反应式编程提供了一些非常强大的概念。但是据我们所知 with great power comes great responsibility。

我们在哪里画线？是否可以在我们的整个程序中填充出色的反应式单行代码，还是应该仅将其保存用于真正平凡的操作？

显然，这是非常主观的，但是我希望有更多经验的人可以分享他的知识和陷阱。
让我说得更好


我如何设计代码以使其具有反应性但易于阅读？

最佳答案

当您拿起Rx时，它变成了这个令人敬畏的闪亮hammer，一切开始看起来像一个生锈的钉子，等着您来敲。
就我个人而言，我认为最大的线索是反应框架的名称。给定要求后，您需要考虑反应式解决方案是否真正有意义。
在任何Rx提议中，您都希望引入一个或多个事件流并针对事件进行一些操作。
我认为有两个关键问题要问：

您可以控制事件流吗？
您必须在多大程度上以事件流的速度完成响应？

如果您无法控制事件流，并且必须以事件流的速率进行响应，则Rx是不错的选择。
在任何其他情况下，这可能都是一个糟糕的选择。
我已经看到很多例子，人们为了达到Rx的正确性而跳了起来，产生了缺乏控制的幻想-在我看来，这很疯狂。为什么要放弃您的控制权？
一些例子：

您必须从固定的文件列表中提取数据并将其存储在数据库中。您决定将每个文件名放入主题中，并创建一个反应性管道，该管道打开每个文件并投影数据，然后以某种方式处理数据，最后将其写入数据库。
这使控制测试和速率测试失败。遍历文件并将其拉入并尽快处理它们会容易得多。短语“决定推动”是这里的赠品。

您需要显示来自证券交易所的股票价格。
显然，这对于Rx是一个不错的选择。如果您无法跟上一般的价格水平，那您将大受打击。您可能会合并价格（也许每秒仅提供一次更新），但这仍然可以跟上价格。您无法做的一件事就是要求证券交易所放慢脚步。


这些（真实世界）示例几乎落在光谱的两端，并且没有太多的灰色区域。但是有很多灰色区域尚不清楚控制权。
有时，您在客户/服务器系统中戴着客户帽子，很容易陷入牺牲控制的陷阱，或者将控制放在错误的位置-可以通过正确的设计轻松修复。考虑一下：

客户端应用程序显示来自服务器的新闻更新。

新闻更新会随时提交到服务器，并且会大量创建。
客户端应按客户端设置的间隔刷新。
刷新间隔可以随时更改，用户始终可以请求立即刷新。
客户端仅显示由用户指定的带有特定关键字的更新。
新闻更新有时会很长，客户不应存储新闻更新的全部内容，而应显示标题和摘要。
根据用户要求，可以显示文章的全部内容。



在这里，新闻更新的频率不受客户端控制。但是所需的刷新率和感兴趣的标签都是。
对于客户端来说，要在它们到达时接收所有新闻更新并对其进行过滤，客户端将无法正常工作。但是有很多选择：

服务器是否应该发送考虑客户端刷新率的更新数据流？如果客户端下线怎么办？
如果有成千上万的客户怎么办？如果客户希望立即刷新怎么办？

有很多解决此问题的有效方法，包括或多或少的反应性元素。但是，任何好的解决方案都应考虑客户端对标签的控制和所需的刷新率，以及缺少对新闻更新频率（由客户端或服务器控制）的控制。您可能希望服务器通过更新推送给客户端的事件来响应客户端的兴趣变化-事件仅在客户端正在侦听时才推送（通过心跳检测）。当用户想要完整的文章时，客户端将拉下文章。
Rx社区中有很多关于背压的争论。这是一种想法，即客户机应在服务器过载时通知服务器，并且服务器应以某种方式减少事件流来作出响应。我认为这是一种会导致设计混乱的错误方法。
在我看来，只要客户需要提供反馈，它就无法通过响应率测试。在这一点上，您不是处于被动状态，而是处于异步枚举状态。即，当客户端准备就绪时，客户端应该说“我准备就绪”，然后以非阻塞方式等待服务器响应。
如果将第一种情况修改为到达投递文件夹的文件，文件的长度和处理复杂性各不相同，那么这将是适当的。客户端应对下一个文件进行非阻塞调用，对其进行处理并重复。 （根据需要添加并行性）-而不响应文件到达的事件流。
包起来
我特意避免了其他有效的顾虑，例如代码的可维护性，Rx本身的性能等。多数是因为这些问题在其他地方得到了解决，更重要的是，因为我认为此处的想法比这些关注点更具分歧。
因此，如果您在方案中考虑控制和响应率的要素，那么您可能会走上正确的道路。
响应率问题可能很微妙-学位方面很重要。到达率可能会波动，并且响应率会有一定程度的可接受的波动-显然，如果您最终没有办法“追赶”，那么在某个时候客户会崩溃。

关于system.reactive - 用响应式(Reactive)编程画线的地方，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35974063/

上一篇：xcode - Cordova应用程序无法使用Xcode 7.3存档(未找到Cordova/CDVViewController.h'文件)

下一篇：amazon-web-services - 如何使用cloudformation模板创建cloudwatch事件？

相关文章：

system.reactive - subscribeOn 和 observeOn 应该只由最终订阅者调用吗？

java - 先前完成后添加新订阅

java - RxJava2 - Mutlicasting Singles、Maybes 和 Completables？

android - 将现有的 WebSocket 实现转换为 Android Java 中的 Reactive WebSocket

android - 如何在 MediaPlayer 应用程序中限制/去抖搜索栏搜索事件

.net - RX : how to parallelize some long running tasks and synchronize others

java - RxJava doOnError 和 onErrorReturn 如何工作？

c# - 什么是 System.Reactive.Linq.Observαble？ (注意阿尔法)

java - 如何使用 RxJava 使用另一个流的元素属性作为条件来过滤一个可观察流？

kotlin - 如何创建无限间隔的Observable，它将在每个时间间隔发出新的Object？

Answer 1

当您拿起Rx时，它变成了这个令人敬畏的闪亮hammer，一切开始看起来像一个生锈的钉子，等着您来敲。
就我个人而言，我认为最大的线索是反应框架的名称。给定要求后，您需要考虑反应式解决方案是否真正有意义。
在任何Rx提议中，您都希望引入一个或多个事件流并针对事件进行一些操作。
我认为有两个关键问题要问：

您可以控制事件流吗？
您必须在多大程度上以事件流的速度完成响应？

如果您无法控制事件流，并且必须以事件流的速率进行响应，则Rx是不错的选择。
在任何其他情况下，这可能都是一个糟糕的选择。
我已经看到很多例子，人们为了达到Rx的正确性而跳了起来，产生了缺乏控制的幻想-在我看来，这很疯狂。为什么要放弃您的控制权？
一些例子：

您必须从固定的文件列表中提取数据并将其存储在数据库中。您决定将每个文件名放入主题中，并创建一个反应性管道，该管道打开每个文件并投影数据，然后以某种方式处理数据，最后将其写入数据库。
这使控制测试和速率测试失败。遍历文件并将其拉入并尽快处理它们会容易得多。短语“决定推动”是这里的赠品。

您需要显示来自证券交易所的股票价格。
显然，这对于Rx是一个不错的选择。如果您无法跟上一般的价格水平，那您将大受打击。您可能会合并价格（也许每秒仅提供一次更新），但这仍然可以跟上价格。您无法做的一件事就是要求证券交易所放慢脚步。


这些（真实世界）示例几乎落在光谱的两端，并且没有太多的灰色区域。但是有很多灰色区域尚不清楚控制权。
有时，您在客户/服务器系统中戴着客户帽子，很容易陷入牺牲控制的陷阱，或者将控制放在错误的位置-可以通过正确的设计轻松修复。考虑一下：

客户端应用程序显示来自服务器的新闻更新。

新闻更新会随时提交到服务器，并且会大量创建。
客户端应按客户端设置的间隔刷新。
刷新间隔可以随时更改，用户始终可以请求立即刷新。
客户端仅显示由用户指定的带有特定关键字的更新。
新闻更新有时会很长，客户不应存储新闻更新的全部内容，而应显示标题和摘要。
根据用户要求，可以显示文章的全部内容。



在这里，新闻更新的频率不受客户端控制。但是所需的刷新率和感兴趣的标签都是。
对于客户端来说，要在它们到达时接收所有新闻更新并对其进行过滤，客户端将无法正常工作。但是有很多选择：

服务器是否应该发送考虑客户端刷新率的更新数据流？如果客户端下线怎么办？
如果有成千上万的客户怎么办？如果客户希望立即刷新怎么办？

有很多解决此问题的有效方法，包括或多或少的反应性元素。但是，任何好的解决方案都应考虑客户端对标签的控制和所需的刷新率，以及缺少对新闻更新频率（由客户端或服务器控制）的控制。您可能希望服务器通过更新推送给客户端的事件来响应客户端的兴趣变化-事件仅在客户端正在侦听时才推送（通过心跳检测）。当用户想要完整的文章时，客户端将拉下文章。
Rx社区中有很多关于背压的争论。这是一种想法，即客户机应在服务器过载时通知服务器，并且服务器应以某种方式减少事件流来作出响应。我认为这是一种会导致设计混乱的错误方法。
在我看来，只要客户需要提供反馈，它就无法通过响应率测试。在这一点上，您不是处于被动状态，而是处于异步枚举状态。即，当客户端准备就绪时，客户端应该说“我准备就绪”，然后以非阻塞方式等待服务器响应。
如果将第一种情况修改为到达投递文件夹的文件，文件的长度和处理复杂性各不相同，那么这将是适当的。客户端应对下一个文件进行非阻塞调用，对其进行处理并重复。 （根据需要添加并行性）-而不响应文件到达的事件流。
包起来
我特意避免了其他有效的顾虑，例如代码的可维护性，Rx本身的性能等。多数是因为这些问题在其他地方得到了解决，更重要的是，因为我认为此处的想法比这些关注点更具分歧。
因此，如果您在方案中考虑控制和响应率的要素，那么您可能会走上正确的道路。
响应率问题可能很微妙-学位方面很重要。到达率可能会波动，并且响应率会有一定程度的可接受的波动-显然，如果您最终没有办法“追赶”，那么在某个时候客户会崩溃。