I heard on twitter the other day (Yes, I now tweet occasionally. If you'd like to waste literally seconds of your day you can follow me at joshtwist) that some folks at an Alt.Net UK event where giving P&P and Prism a rough ride. Specifically, they had some issues with the EventAggregator - citing Jeremy Miller's criticisms in this post Braindump on the Event Aggregator Pattern.

I need to say up front that I really like the EventAggregator in Prism - it's one of my favourite bits. However, I have to agree with some of the feedback. I've always found it odd that I have to go to the EventAggregator and ask for an 'event' object. Especially because the thing I get back isn't an event, but the 'bus' through which events travel.

However, once I've learned the API I've never found it obstructive. Nonetheless - I wondered, how hard would it be to create a wrapper that makes the Event Aggregator look something like you might expect it to look?

The interface would look something like that I guess. And it would be used like so.

eventAggregator.Subscribe<Customer>(c => CustomerHasBeenSelected(c));

// meanwhile, elsewhere...

eventAggregator.Send(customer);

That certainly feels a bit better. However, there's no 'topic' described so this feels like a poor usage of the new interface as I can't distinguish Customer *selection* from other events involving the Customer type. Maybe this is better:

"I also realise that most of this could have been implemented in Extension Methods but I think a separate, uncluttered API would be more intuitive"

Ta

Josh

Posted by
Laurent Bugnion
@
27 Sep 2009
2:37 AM
The syntax you propose is quite exactly what I have in my Messenger class (part of the MVVM Light Toolkit) V2, which I will publish these coming days. It was developed in collaboration with Glenn Block, mostly based on feedback from the Prism EventAggregator.

I will try to push a beta out today, it is implemented and tested, just need to write a smal blog post about it. I still have a little work in the installer and should be ready with V2 final very soon.

Posted by
Shimmy
@
11 May 2011
8:58 PM
I would want even less sucky, something like below where you don't have to pass an argument at all, like Subscribe<UserLoggedOutEvent>() where the event type is just used as a body class for generic distinguishing.