I understand the IObservable & IObserver are implementations of the observer pattern and can be used in similiar circumstances to .Net events.
I was wondering if there is any relationship to INotifyPropertyChanged?
I currently use INotifyPropertyChanged for data binding in winforms & WPF applications and was wondering if I'll be able to use IObservable in UI data binding scenarios?
Cheers
AWC
Unless WinForms and WPF bindings also support IObservable, it won't help to keep the UI updated with changes in the model. The reason that you can use INotifyPropertyChanged is because the bindings code in WinForms and WPF looks for this interface, and when implemented uses its event to keep the UI up to date.
From what I can gather, there is no relationship. Observers/.NET eventing are two ways of achieving the Observer/Notification style behavior.
Microsoft's answer has been to build on top of the .NET eventing pattern, not deprecate it in favor of manually registered Observer objects.
One of my biggest peeves with events is the inability to clear the delegate chain on demand, which leads to quite a few managed-memory leak scenarios. To this end, Microsoft introduced the concept of weak events, that is, to address the issue of mismatched timelines for Observables/Observers.
You can read more about the WeakEvent pattern here.
Josh Smith has released an implmentation of the WeakEventManager for INotifyPropertyChanged here. This provides a safer (from a memory-standpoint) way of hooking up objects which change properties, and their Observers.
If you mean IObserver/IObservable as defined by the Rx extensions:
and:
http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html
Then its like apples and oranges.
INotifyPropertyChanged just provides a common event hookup for databinding/etc to let controls know when to update their bound values.
IObservable/IObserver is more like "querying with sequences of events", but even that is a poor description.
Hmm...ok, so you know how you can put stuff in this "bag" called a collection, and then query that collection (manually or with a LINQ statement) to pull out the values, right? It's kind of like that, but instead of "pulling" data out of a "bag", you are getting events "pushed" to you.
Shameless plug that might help or further confuse: http://blog.lab49.com/archives/3252
First off, I'm a bit new to Rx, so take my comments accordingly.
That said, I think that there is a great opportunity for cooperation between INotifyPropertyChanged and Rx's IObservable. I think it's relatively obvious that the UI is built around INPC at this point. However, INPC is also a primary way of detecting changes and managing scenarios where a domain model or view model has interdependencies between objects and properties. It is these interdependencies that seem like good candidates for Rx.
Working with INPC directly is a bit tricky and somewhat painful. Lots of magic strings to deal with. It is also a bit painful to watch for an event on an object multiple levels away in the object tree.
But if I can model these interactions "reactively", then my view models and domain models start to feel a bit more elegant. This is evident in the elegance of projects like Bindable Linq, Continuous Linq, Obtics, etc. These libraries make it simple to create "live values" or "live collections" that update automatically (dare I say "reactively") to changes. Continuous Linq even has a "reactive object" framework to do reactive programming, albeit without Rx.
It seems to me that the synergies come in if we can use Rx to keep the model and view model coherent. Then we can make the "bindable surface" of the model / view model honor the INPC by continuing to raise PropertyChanged as needed. I've seen a couple elegant extension methods that will create an observable from INotifyPropertyChanged. It seems that the other half of this might be to create some infrastructure that translates from Rx back to INPC.