How To Choose Between Different Methods of Handling/Raising Events?

Question

In situations where I need to write observer/subscriber code, how would I choose between the following approaches?

A) Declaring an event that simply notifies a client something happens but requires the client to make a query for data e.g.

class SoothSayer{

    int DaysUntilApocalypse{get;}

    event EventHandler<EventArgs> TheEndIsNigh;

}

B) Declaring an event with specific XXXEventArgs containing the event data e.g.

class SoothSayer{

    event EventHandler<ApocalypsePendingEventArgs> TheEndIsNigh
}

class ApocalypsePendingEventArgs:EventArgs{
    int DaysLeft{get;}
}

C) Using a callback rather than an event e.g.

class SoothSayer{

    public SoothSayer(Action<int> endIsNighCallback){
        _endIsNightCallBack = endIsNighCallback;
    }
}

Answer 1

Version (c) is a form of continuation passing, it is not an event at all. It is a wholly different method of control flow, and can be used to express some complex types of control flow that are difficult to express with primitive constructs such as loops and conditionals. For example, it's the basis for asynchrony in C# 5. All await really does, in essence, is pass a continuation.

It is certainly a valid construct, but the answer to when you should use this for event-driven programming is never, because it's not an event. There is no subscription of any kind; the callback is coupled to method call. You also can't have multiple subscriptions, which you can have with any old event.

So it comes down a choice between (a) using a plain EventHandler or (b) using a custom MyEventHandler with event data. And the answer to that is simple: use a custom event if there is important, transient data associated with the event.

Imagine if you had to query for the cursor position every time you executed a MouseDown event handler. It would be completely unreliable, because the mouse position could and often would change between the time the event was fired and the time it was handled. On the other hand, an Initialized event is pretty self-explanatory; it's only going to happen once in the lifetime of an object and there's really not much else to say about it other than "OK, I'm ready!".

So, in summary, (a) use the default EventHandler when you've got nothing else interesting to say, (b) use a strong-typed EventHandler<T> when you do, and (c) don't use CPS for event notifications.

Answer 2

I guess the Question itself has got answer. That depends on the scenario.

If you intend just a notification od a particular thing happened and the subscriber has all the data (or does not require any more data from publisher, at the least), then use Method A

if you want to pass some data that the publiser only has , also which is needed by the subcriber Use Method B

Giving some pseudo code for a hypothetical scenario:

 Class ClosedRoom
 {

      event: RoomOverHeatingHappened//notification
      event: RoomOptimalTemperatureReached//notification

      event: WindowOpenedOrClosed(int WindowNumber,Bool isOpened)//it notifies + tells which of the 4 windows got opened/closed + whether it is opened or closed

 }

Answer 3

So event based programming is not really messaging. Messaging frameworks exist within .NET, but aren't hugely abundant. Messaging normally leads to Actors http://en.wikipedia.org/wiki/Actor_model. Actors are a totally different way to deal with systems (and often make multi-threaded software much easier) than just some basic eventing.

https://github.com/phatboyg/stact Actor framework

http://msdn.microsoft.com/en-us/devlabs/dd795202 Axum is Microsoft shuttered actor compiler

http://code.google.com/p/retlang/ Sorta messaging/actor framework