IObservable vs Plain Events or Why Should I use IObservable?
EventsDesign Patterns.Net 4.0system.reactiveEvents Problem Overview
Microsoft introduced the [IObservable<T>
interface](http://msdn.microsoft.com/en-us/library/dd990377.aspx "MSDN reference page") to the BCL with .NET Framework 4, and I thought, "Great, finally, I must use it!" So I dug deep and read posts and documentation and even implemented the pattern.
After doing so I've realized that the basic implementation actually sends all the T
events to all of its subscribers without any filtering on it; i.e. plain broadcast. I read somewhere that the Observable pattern is meant for plain broadcast. I feel that this is not true and that I am missing something.
My questions:
-
If I add a filtering mechanism, what is the difference between using the Observable pattern and just using plain CLR events?
-
When should one use this pattern, and when should one choose to use plain CLR events?
-
What are the main advantages of the Observable pattern?
Events Solutions
Solution 1 - Events
Observable is the cornerstone of the Rx library. They provide pretty much all the implementations and operators you'll need. The idea behind IObservable<T>
and Rx
is not just the "handling" of events, but enabling "LINQ to Events." So you can easily compose "event streams," which gives you a lot of power compared to regular event handling.
Note that the sample MSDN implementation of IObservable<T>
is incorrect; the doc team has been notified.