Geek Answers Handbook

Where to use Rx?

I am going to bring Rx to my workplace, but the more I learn about it, the more I think that this does not give you an advantage.

We have many server applications that take input at one end and output it at the other end. Which is ideal for the actor model and the "infinite" scalability of threads, so far I have used ConcurrentQueues to implement messaging, and I thought that Rx might be a more functional alternative that could make concurrency more implicit, which helps me move some flow decisions data from the imperative code to the declarations observable.

But reading about it and trying this, I don’t see much advantage over using regular old threads with ConcurrentQueues for message passing. What benefits does Rx give me? It is always said that although .NET 4.5 made a lot of Rx obsolete (although async and Dataflow), it is still good for handling event streams. What cases represent event flows and how to identify them?

+6
source share
2 answers

If you need to parallelize some tasks, use TPL.

If you need to perform asynchronous operations, use Task and async/await .

If you need to receive, filter, and combine event streams, use Rx. Please note: Rx is not necessarily asynchronous - it's just a model for handling event streams in the same way that LINQ is a model for working with collections.

Your use case sounds like the first option.

+4
source

There are many similar questions on SO ....

Rx is the whole composition of asynchronous operations based on mathematics. TPL and "plain old themes" are not composite. You should see non-trivial examples before you can see which composition is really beneficial to you.

Take a look at this Intro page on Rx (and the rest), and I'm sure you will begin to feel the reasons for Rx: http://introtorx.com/Content/v1.0.10621.0/01_WhyRx.html#WhyRx

+1
source

More articles:


All Articles