Yea another simplification of Prism’s EventAggregator syntax

It’s been quite a while since I worked with Prism’s EventAggregator. Today however I need to use it. As soon as I started to write my code, I heard my friend Jeremy Miller in my head saying how much he hates the ceremony of GetEvent<> pattern that Prism’s EA introduces. What he is talking about is code like the following

//publisher

publicclass OrderController {

private IEventAggregator _ea;

public OrderController(IEventAggregator ea) {

_ea = ea;

}

publicvoid SelectOrder(Order order) {

_ea.GetEvent<OrderSelected>().Publish(order);

}

}

//subscriber

publicclass OrderViewModel {

public OrderViewModel(IEventAggregator ea) {

ea.GetEvent<OrderSelected>().Subscribe(OnOrderSelected());

}

publicvoid OnOrderSelected(Order o) {

}

}

As you can see above, that each time I need to publish or subscribe, I am calling GetEvent<T>

I then found my way back to my buddy Ward’s post on the subject here: http://neverindoubtnet.blogspot.com/2009/07/simplify-prism-event-aggregator.html. In that post, Ward suggested that a way to deal with this was to create an event say OrderSelected which derives from CompositePresentationEvent<OrderSelected>and in so doing removes the need for a special payload class as the event is the payload. He then adds a set of extension methods directly to EA for handling Publish and Subscribe. Using my example above the code would now look like this with his extensions.

//publisher

publicclass OrderController {

private IEventAggregator _ea;

public OrderController(IEventAggregator ea) {

_ea = ea;

}

publicvoid SelectOrder(Order o) {

_ea.Publish<OrderSelected>();

}

}

//subscriber

publicclass OrderViewModel {

private IEventAggregator _ea;

public OrderViewModel(IEventAggregator ea) {

ea.Subscribe<OrderSelected>(OnOrderSelected);

}

publicvoid OnOrderSelected(Order o) {

}

}

Which is much much cleaner. There’s no longer any need for calling GetEvent<T>(). However, there’s two parts about the approach that I just had a hard time digesting. I am not saying it is a bad approach but:

It requires the event class to inherit from CompositePresentationEvent<T> when I would prefer not having to carry any base class requirement.

It requires that the T that it inherits from is itself.

And so over a year later, I decided to take another crack at it with a slightly different approach. This one doesn’t require any base class so it removes the 2 constraints above. It basically uses extension methods to wrap / unwrap the passed in parameter with CompositePresentationEvent. It removes you from having to know about that event at all.

Rather than chop it up to make it fit the narly CodeBetter column constraints, go grab it at CodePaste here

Makes the code nice and clean. Now my event classes are just simple pocos. It also also maintains the nice syntax that Ward achieved in his pioneering approach that led me down this path.

Next step is we need an IoC autowireup facility for EventAggregator, that would make Jeremy very happy