I have an object which will periodically raise an event based on an action performed in an application. This will be heard by any listener(s) and acted upon accordingly.
I do not wish to use a custom type for this and would like to make use of either EventHandler<T> or IObservable<T> to manage the pub/sub mechanism I am looking to put in place.
I have had a play with both and they both do what I require.
I have read through the MSDN Observer Design Pattern and MSDN Events Programming Guide, however, I remain uncertain as to if one mechanism is more appropriate than the other.
Is one more suited for my scenario than the other or are both suitable and merely down to personal choice?
Edit 1
My pub/sub requirements are not at the UI layer at this point and are lower down. My publisher is monitoring network activity and raising an event based on certain network events. The subscriber is responsible for listening for raised events and performing an associated action. The UI is not involved at this point.
As I understand it, the Observable pattern concerns itself traditionally with real-time binding of a User Interface, based on changes in the underlying data store. In other words, a UI that subscribes to an IObservable<T> has updates pushed to it when the underlying data store changes.
Event Handlers are a more generalized mechanism. They are used for all sorts of things, both inside the UI and elsewhere. Fundamentally, EventHandler<T> is really just a formal definition for a delegate signature that’s been around since the beginning of Windows Forms.
2
Have you looked at Reactive Extensions? Reactive Extensions is a library that allows the composition of aysynchronous and event based code. I’d have a look at Intro To Rx, it has lots of information on when IObservable is appropriate and as J Trana has said one of the benefits is a reduction in coupling.
Without more information about your application it’s hard to advise specifically which approach I would recommend.
When I think about events, I usually think about them in the context of how tightly coupled they are.
EventHandler style eventing is very concrete and tightly coupled. I feel it is appropriate in the same sorts of situations you would use a concrete class vs. an interface for something. It is the “built-in” approach to .NET and mirrors get/set on properties with add/remove. Make sure you consider locking within your add/remove’s if you go this route.
IObservable< T> style eventing is less concrete. You may have one or more objects that could be passed around as the same IObservable< T>. It also provides an error-handling and a completion mechanism.
Event aggregation is a third option, one that I’ve used and liked. It provides even looser coupling and helps subscribers and publishers be quite ignorant of the details of each other. It also makes dispatching events on different threads easier.
In general, tightly coupled mechanisms are simple to write and simple to debug, but provide less flexibility as an application grows. Loosely coupled mechanisms are still easy to write but can be much less simple to trace when you’re looking at an unfamiliar code base. At any rate, make sure you also understand the lifetime of subscriber objects when implementing these patterns (primarily the tightly coupled ones), as not letting go of objects is a trap. MSDN has a nice little section on event coupling.
Unfortunately, I don’t see enough description about your program to understand what level of coupling you need but I hope this helps you make the right choice.