aggie
aggie

Reputation: 798

INotifyPropertyChanged vs IObservable - RxExtensions, which one for observer pattern

Massive re-factoring at business layer core here, and I need some help with choosing/implementing the better design pattern, and implementation.

Question:

  1. in the ASP MVC, business layer context, when does IObservable dominate INotifyPropertyChanged
  2. Which one is a better implementation for the design pattern for a genericObserableFactoryObject
  3. I really like the weakEventListener because of the lower prob on memory leaks, http://msdn.microsoft.com/en-us/library/hh199438.aspx, does this apply only to threads and thread dispatching

My due-diligence: I understand INPC is at property level and the other is ~more at an conceptual object level, but with the LINQ it seems IObservable might be the choice. However, the simplicity and flexibility to embedded inside any object is tempting.

So, I just need some help in understanding the design intent/purpose/motive of both, and which one would be the best reuse for an observer pattern factory.

Also, know any place, I can get the code snippet for observer factories

Upvotes: 6

Views: 4452

Answers (2)

mikalai
mikalai

Reputation: 1736

MSDN says pretty clear.

IObservable

The IObserver<T> and IObservable<T> interfaces provide a generalized mechanism for push-based notification, also known as the observer design pattern.

INotifyPropertyChanged

The INotifyPropertyChanged interface is used to notify clients, typically binding clients, that a property value has changed.

As far as I understand, INotifyPropertyChanged was added long ago (for example, it had been used in WS clients and later it because most important interface in WPF binding handling).

So I assume that answer is fuzzy and clear: if you really need observer pattern, use IObservable.

Upvotes: 4

Lee Campbell
Lee Campbell

Reputation: 10783

As far as I know, the primary usage of INPC is for clientside view data-binding (i.e. WPF, Silverlight). You can definitely use INPC in apps that are not for view binding, but you have a clunky string thing (PropetyName) happening here. The upside of using that is you only need one event for the whole object and the the property name is specified in the event (or empty string for the whole object should be considered changed). Alternatively you could have a XXXPropertyChanged event for each event

IObservable<T> is just an alternate implementation of the Observer pattern (ie. an alternate to .NET events). Instead of exposing an event from your class, you would expose an IObservable<T>. Instead of raising the event, you just OnNext values to the observable sequence. IObservable<T> also has the extra benefits of having the concept of a sequence termination via OnError or OnCompleted. So in this case, a better question would be should I use Events or IObservable<T>. To answer this question I would suggest favouring IObservable<T> unless the target audience/consumer does not want to concern themselves with learning Rx.

That was a fairly naive differentiation between the two, however I expand the concept more here http://introtorx.com/Content/v1.0.10621.0/01_WhyRx.html#WhyRx

Upvotes: 5

Related Questions