Reactive Framework Why bother
Now that LINQ has been out for a while, I’m starting to work on a new set of talks that are related to some of the new extensions to LINQ. Although LINQ to databases (SQL, Entity Framework, etc) are interesting, I’ve always been partial to the more generalized abstraction that is found in LINQ to Objects and XML. One of the most compelling expansions on the core LINQ concepts at this point is the Reactive Framework (rX).
With the Reactive Framework, we flip the paradigm of Enumeration and pulling for more results upside down. Instead of pulling for the next record, the Reactive Framework “Reacts” to events as they are pushed through the event pipeline. Instead of calling MoveNext as we do with IEnumerable, we react to OnNext events.
So when would you use this Reactive framework? Essentially, you can use it anywhere you are responding to events or work with continuous streams. Some sample cases are:
- Handling UI Events (Mouse clicks, Touch gestures)
- Working with Asynchronous Web requests (Web services)
- Analyzing sensor data from Manufacturing, Power, Health care, Telecom, etc. devices. real time.
- Processing data from continuous data streams (Log files, Stock feeds, etc.)
Many of the samples out there currently demonstrate the first two scenarios, but there aren’t too many examples (yet) on the other scenarios. Over the next few months, I hope to dig into the Reactive Framework and related IObservable based technologies (like SQL Server 2008 R2 StreamInsight) and offer some practical examples where the Reactive Framework can make your programming life easier.
Update: Here are a couple reasons why Rx is useful as compared to traditional events as well:
- You can replace implementation for mocking/testing purposes
- Compose complex operations over multiple event/observable streams
- LINQ like filtering and projection for common programming model.
- Easy to clean up resources with Dispose