Question

I am trying to understanding the Event Aggregator pattern from an architecture and design view point. I have never used Prism in WPF before, but I’m studying how it works on MSDN.

It seems to me that for every event, the user has to create a new event object that extends the CompositePresentationEvent. It also appears that the new event object has no functionality other than those it inherited from (it usually has no code for itself).

So for example:

A AddNewStuffEvent would look like:

public class AddNewStuffEvent : CompositePresentationEvent<Object> {} //The end of the class

For a HealthChangeEvent:

public class HealthChangeEvent: CompositePresentationEvent<Object> {} //The end of the class

For a BookFlipEvent:

public class BookFlipEvent: CompositePresentationEvent<Object> {} //The end of the class

For a BookCloseEvent:

public class BookCloseEvent: CompositePresentationEvent<Object> {} //The end of the class

And this can go on forever for every little small event for BookOpenEvent, BookTearEvent, etc. So, in a particular namespace folder, there will be a whole ton of event classes, and the Event Aggregator is going to be loaded with all these event objects during runtime. That’s, every little small event needs an empty class? Is this how it works? What could be a better way for this?

Answer 1

Yes, every event type needs its own class, which you have to define.

It also appears that the new event object has no functionality other than those it inherited from

The purpose is simply to provide strong typing for the event. This makes it easier to write code to subscribe to them. Ie, the subscribing code can be written like:

aggregator.GetEvent<AddNewStuffEvent>().Subscribe(Handler);

This is a preferable approach to alternatives, such as reliance on “magic strings” in the form of say aggregator.GetEvent("AddNewStuffEvent").Subscribe(Handler) (which could not be verified at compile time.