Rx应该在哪些场景下使用？

Question

Rx应该在哪些场景下使用？

9

我正在考虑在我的工作场所引入Rx，但是我了解得越多，就越认为它并没有真正给你带来优势。

我们有很多服务器应用程序，在一端接收输入数据，在另一端输出数据。这非常适合使用Actor模型和“无限”线程可扩展性，到目前为止，我使用ConcurrentQueues实现消息传递，我认为Rx可能是一个更好的函数式替代方案，可以使并发更加隐式，从而将一些数据流决策从命令式代码转移到可观察对象的声明中。

但是，在阅读相关资料并尝试使用后，我并没有看到与使用普通旧线程和ConcurrentQueues进行消息传递相比的优势。Rx给我带来了哪些优势？虽然.NET 4.5使Rx过时了很多（尽管有异步和Dataflow），但据说它仍然适用于处理事件流。哪些情况会出现事件流，我该如何识别它们？

- Ziv

你可能会发现Netflix使用Rx很值得一看，因为它似乎对他们非常有效。https://blogs.msdn.com/b/interoperability/archive/2013/02/05/netflix-solving-big-problems-with-reactive-extensions-rx.aspx - Wilka

作为（非常粗略的）经验法则，如果您正在处理单个值，请使用TPL/Task API；如果您正在处理"事件"序列（泛指"某些东西"，而不仅仅是.NET事件），请使用Rx。我对数据流不太熟悉，需要考虑一下。 - JerKimball

2个回答

1

在SO上有很多类似的问题...

Rx主要是关于异步操作的数学组合。TPL和“普通的线程”是非组合的。您必须看到非平凡的示例，才能看到组合真正为您带来的好处。

请查看Intro to Rx页面（以及其余部分），我相信您会开始理解Rx的原因： http://introtorx.com/Content/v1.0.10621.0/01_WhyRx.html#WhyRx

- Richard Anthony Freeman-Hein

好的链接，如果你不确定 Rx 的“目的”，那么阅读它是值得的。 - Alex

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Alex · Accepted Answer

如果你需要并行一些任务，使用 TPL。

如果你需要执行异步操作，请使用 Task 和 async/await。

如果你需要接收、过滤和合并事件流，请使用 Rx。请注意，Rx 不一定是异步的——它只是处理事件流的模型，就像 LINQ 是处理集合的模型一样。

根据你的情况，第一种选项听起来更适合。