System.Reactive.dll<\/code>) in the sources of the current Silverlight 3 Toolkit<\/a>. It’s used there to get some smoother Unit Tests to work.<\/p>\nThe aim of Rx is to simplify\/unify complex event-based and asynchronous programming by providing a new programming model for those scenarios. That’s very important in a world which becomes more and more async (Web, AJAX, Silverlight, Azure\/Cloud, concurrency, many-core, …) and where present approaches (event-based programming with .NET events, Begin\/Invoke) hit the wall. Program logic gets hidden in a sea of callback methods which leads to nasty spaghetti code<\/a><\/em>. Those of you who are creating larger async programs know what I mean \ud83d\ude09<\/p>\nBasic ideas<\/h3>\n
The main concept of Rx is reactive programming<\/strong><\/a> and that’s not new at all. It involves a distinction of data processing methods into push<\/em> and pull<\/em> scenarios:<\/p>\n\n- In a pull<\/em>-scenario<\/strong> your code\/program is interactively<\/em> asking for new data from the environment. In this case the actor is your program while it pulls new data from the environment.<\/li>\n
- In a push<\/em>-scenario<\/strong> your program is reactive<\/em>. The environment in pushing data into your program which has to react on every new incoming data item (see illustration below). Reactive programs are ubiquitous: every event-handler (e.g. for UI events) is an example for a reaction in a push-scenario.<\/li>\n<\/ul>\n
![\"Reactive](\"http:\/\/www.leading-edge-dev.de\/wp-content\/uploads\/2009\/10\/Reactive_Programming1.png\" "\\"Reactive")
<\/a><\/p>\nThe guys at Microsoft got a very important insight which builds the fundament of Rx: there’s a dualism<\/em><\/a> between the Iterator<\/a> and the Observer<\/a> pattern<\/strong>! This means that both patterns are essentially the same, if you dismiss their practical intentions for a moment.
\nWith the Iterator<\/em> pattern you get a sequence of data which is iterated in the pull<\/em>-mode: the Iterator is the actor and asks the iterable object for data.
\nThe Observer<\/em> pattern can be interpreted equivalently: the environment pushes data into your program (e.g. through events), which has to react. As result with repeatedly fired events you get a sequence of data, which makes the relationship to the Iterator pattern obvious.<\/p>\nWith this, an Observer in the push-scenario is equal to an Iterator in the pull-scenario and that’s the key insight, which has led to the development of the Reactive Framework. 14 years had to pass from the publication of the GoF Design Patterns<\/a> book until now to figure out this intense relationship of the Iterator and the Observer pattern.<\/p>\nLINQ to Events<\/h3>\n
Rx realizes the Observer pattern with the two interfaces IObserver<\/code> and IObservable<\/code> which are the pendants for IEnumerator<\/code>\/IEnumerable<\/code> of the Iterator pattern. IObservable<\/code> is a sort of „asynchronous collection“, which represents the occurrence of a certain event at different points in time. Thus it expresses a sequence of data, on which you can run arbitrary actions. In fact IObservable<\/code> for push<\/em>-scenarios is essentially the same as IEnumerable<\/code> for pull<\/em>-scenarios.<\/p>\nThe interplay of IObservable<\/code> and IObserver<\/code> is the following: on an IObservable<\/code> you can register (Subscribe()<\/code>) an IObserver<\/code> (Note the dualism to IEnumerable<\/code>\/IEnumerator<\/code> here!). The IObserver<\/code> has three methods OnNext()<\/code>, OnCompleted()<\/code> and OnError()<\/code>. These methods are invoked when the IObservable<\/code> gets new data, completes the data sequence or results in an error. Thus your IObserver<\/code> implementations take care of the data processing which replaces your custom callback methods.<\/p>\nThe real impressing thing with Rx is that with events as data sequences you can use LINQ<\/strong> syntax to process and transform these data sequences (that’s why it’s sometimes called LINQ to Events<\/em>). To create instances of IObservable<\/code> and for providing LINQ methods, Rx comes with the class Observable<\/code>. If you want for example take the first 10 click events on a button but skip the first click, you could easily write:<\/p>\n\r\nObservable.FromEvent(button1, \"Click\")\r\n .Skip(1)\r\n .Take(9)\r\n .Subscribe(ev => MyEventAction(ev));\r\n<\/pre>\nSubscribe()<\/code> has some overloads. In this example I’ve directly specified an action which is executed when an event (= a piece of data) comes in. Instead you could give it e.g. your custom implementations of IObserver<\/code> as well.
\nLINQ gives you real power in processing, composing and transforming your events as data stream. Even in the simple example above, if you would implement it by event-based programming without Rx, you would need some additional effort. You would have to use temporary variables to skip certain elements, take others and so forth. In general, more complex cases require complete finite state machines<\/em><\/a> which can be circumvented with Rx.<\/p>\nComposing events with LINQ is another typical and impressing example for Rx. Thus, a dragging event on a textblock can be implemented as:<\/p>\n
\r\nIObservable<Event<MouseEventArgs>> draggingEvent =\r\n from mouseLeftDownEvent in Observable.FromEvent(textBlock1, \"MouseLeftButtonDown\")\r\n from mouseMoveEvent in Observable.FromEvent(textBlock1, \"MouseMove\")\r\n .Until(Observable.FromEvent(textBlock1, \"MouseLeftButtonUp\"))\r\n select mouseMoveEvent;\r\ndraggingEvent.Subscribe(...);\r\n<\/pre>\nIn this example, with the from<\/code> keyword the two events \"MouseLeftButtonDown\"<\/code> and \"MouseMove\"<\/code> are chained together. Everytime the left mouse button is pressed on the textbox, the „gate“ opens to react on mouse move events. The „gate“ closes again when the left mouse button is released. So the composed stream includes all events where the left mouse button is pressed and the mouse is moved – the typical dragging event!<\/p>\nThere are other possibilities to compose events, which for example consider the order of events differently. Those build the interesting parts of the Reactive Framework and clarify the use cases, where Rx has real advantages over present event-based .NET programming.<\/p>\n
Bottom line<\/h3>\n
Personally I like the new way of thinking of events as data sequence<\/em>! The dualism<\/em> of the Iterator and the Observer pattern has nothing artificially constructed, but some sort of purity and mathematical elegance<\/em> for me. But one big question remains: do we need this in our everyday’s developer life and which advantages come with it?<\/p>\nErik Meijer himself says about Rx:<\/p>\n
Of all the work I’ve done in my career so far, this is the most exciting. […] I know it’s a bold statement, but I really believe that the problem of asynchronous programming events has been solved.<\/p><\/blockquote>\n
That’s a really strong message and it has some important weight since Erik is the creator of LINQ and has a big expertise in language design. Does Rx hold what he promises?<\/p>\n
In my opinion Rx is really beautiful and valuable when you do complex<\/em> asynchronous operations, where you have to compose<\/em> and orchestrate<\/em> events\/data from several sources<\/em>. With Rx you’re able to chain and filter events to easily create the concrete event<\/em>, to which you want to react. That’s the power of LINQ<\/em>, which allows transforming the resulting data as well. LINQ gives you the whole flexibility of processing the data stream that you already know from LINQ to Objects (on IEnumerable<\/code>) etc.<\/p>\nBeyond that at the moment I don’t see a real<\/em> big impact in many current development scenarios. If you have to handle simple<\/em> events or do simple async computations, you are still fine with the present<\/em> event-based programming model. Of course with Rx you can write your own observers to prevent a sea of callback methods, but encapsulation<\/em> of handler logic can be done without that as well. Thus at the end I like the concepts of Rx (Observer, LINQ, …) and I’m curious to see how this whole thing develops after the release of .NET 4.0, but I’m not over-enthusiastic at the moment.<\/p>\nLinks<\/h3>\n
Finally here is a list of links to some interesting websites regarding the Reactive Framework:<\/p>\n
\n- Lang.NET – Live Labs Reactive Framework<\/a><\/li>\n
- Channel9 – Inside the .NET Reactive Framework (Rx)<\/a><\/li>\n
- Channel9- Inside .NET Rx and IObservable\/IObserver in the BCL (VS 2010)<\/a><\/li>\n
- Channel9 – Reactive Framework Under the Hood Part1<\/a><\/li>\n
- Channel9 – Reactive Framework Under the Hood Part2<\/a><\/li>\n
- unfold – Introducing Rx (Linq to Events)<\/a><\/li>\n
- unfold – The Joy of Rx: Extension Events<\/a><\/li>\n
- unfold – The Joy of Rx: The Event-Based Async Pattern vs. IObservable<\/a><\/li>\n
- unfold – The Joy of Rx: Building an Asynchronous API…<\/a><\/li>\n
- Paul Batum – Reacting to the Reactive Framework Series<\/a><\/li>\n<\/ul>\n
![\"kick](\"http:\/\/www.dotnetkicks.com\/Services\/Images\/KickItImageGenerator.ashx?url=http%3a%2f%2fwww.leading-edge-dev.de%2f%3fp%3d501\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"During the last weeks I took some time to have a first look at the Reactive Framework. Here I want to share some\u00a0impressions and information with you. Rx: What is it about? The Reactive Framework (Rx) has been developed at the Microsoft Live Labs and is another creation by Erik Meijer, the father of LINQ. … Reactive Framework (Rx) – first look<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,12],"tags":[182,187,181,186,183,184,185,189,188,179,180,178],"class_list":["post-501","post","type-post","status-publish","format-standard","hentry","category-dot-net","category-design-patterns","tag-asynchronous","tag-dualism","tag-events","tag-iterator","tag-linq","tag-linq-to-events","tag-observer","tag-pull","tag-push","tag-reactive-framework","tag-reactive-programming","tag-rx"],"_links":{"self":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/501","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/comments?post=501"}],"version-history":[{"count":7,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/501\/revisions"}],"predecessor-version":[{"id":934,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/501\/revisions\/934"}],"wp:attachment":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/media?parent=501"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/categories?post=501"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/tags?post=501"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}