IObservable vs Plain Events or Why Should I use IObservable?

EventsDesign Patterns.Net 4.0system.reactive

Events 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:

  1. If I add a filtering mechanism, what is the difference between using the Observable pattern and just using plain CLR events?

  2. When should one use this pattern, and when should one choose to use plain CLR events?

  3. 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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionAdiel YaacovView Question on Stackoverflow
Solution 1 - EventsStephen ClearyView Answer on Stackoverflow