应该在哪里使用 Rx？ [复制]答案

【问题标题】：Where should Rx be used? [duplicate]应该在哪里使用 Rx？ [复制]
【发布时间】：2013-04-01 11:56:33
【问题描述】：

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

我们有很多服务器应用程序在一端接收输入数据并在另一端输出。这对于演员模型和“无限”线程可扩展性来说是完美的，直到现在我已经使用 ConcurrentQueues 来实现消息传递，我认为 Rx 可能是一个更好的功能性替代方案，它可以使并发更加隐式，帮助我移动一些从命令式代码到可观察对象声明的数据流决策。

但是阅读它并尝试它，我认为与使用常规旧线程和 ConcurrentQueues 进行消息传递相比没有太大优势。 Rx 给我带来了哪些优势？人们总是说，即使 .NET 4.5 使很多 Rx 过时（尽管是异步和 Dataflow），它仍然可以很好地处理事件流。什么情况下会出现事件流，如何识别它们？

【问题讨论】：

您可能会发现 Netflix 对 Rx 的使用值得一看，它似乎对他们很有效blogs.msdn.com/b/interoperability/archive/2013/02/05/…
作为一个（非常粗略的）经验法则，如果您正在处理单个值，请使用 TPL/Task api；如果您正在处理“事件”序列（通用“某事”，而不仅仅是 .net 事件），请使用 rx。我不太熟悉的数据流，我不得不考虑一下。

标签： c# system.reactive actor

【解决方案1】：

关于 SO.... 有很多类似的问题。

Rx 是关于异步操作的基于数学的组合。 TPL 和“常规旧线程”是非组合的。您必须先查看重要的示例，然后才能了解该组合对您的真正好处。

看看这个 Rx 简介页面（以及其余部分），我相信你会开始了解 Rx 的原因： http://introtorx.com/Content/v1.0.10621.0/01_WhyRx.html#WhyRx

【讨论】：

好链接，如果你不确定 Rx 的“目的”，值得一读

【解决方案2】：

如果您需要并行化某些任务，请使用 TPL。

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

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

您的用例听起来像是第一个选项。

【讨论】：