What about the Prism EventAggregator?
Many people first come into contact with the Event Aggregator pattern through the implementation in Prism. For my regular readers you may be shocked (shocked I say!) to know that I don’t particularly care for the way they implemented the pattern
in Prism. I think the Prism implementation is clumsy and awkward to use. I despise that idiom of first getting the event aggregator, then retrieving an “Event” object that I’ll then listen to. Same thing with publishing.
I think it’s awkward that I have two steps (get event, then publish) instead of just saying “IEventAggregator.Send().” All of that is unnecessary noise code, and the “get event, then listen/publish” adds a little bit of
overhead to every single unit test that I write that involves either listening to or sending events (more mock object setup, and that would add up more than the extra production code). No, that’s not a huge deal, but noise code adds up, and every
bit of ceremony/noise code I can remove due to infrastructure will make me more productive and the code easier to deal with by making it easier to read.
All I want is to go:
IEventAggregator.Send( the message ). Nothing else.
The listeners should have little or preferably NO/ZILCH/NADA coupling to the event aggregator.
I think Prism is far better than CAB, but it’s still headed for some of the same problems that CAB had. The complexity and awkwardness of the EventAggregator in Prism is directly caused by trying to make the EventAggregator generalized to every
possible scenario that you can think of. You will be able to create a better implementation of EventAggregator for your application by tailoring something simpler for only the things you need. At a minimum, you could at least put an application
specific wrapper around Prism’s generalized API’s to make them easier to consume. I think you could stand to sacrifice some of the flexibility of the Prism EventAggregator and end up with a simpler to consume alternative.
Don’t take this as a specific criticism of Prism itself, because the real issue is that generalized application frameworks are an automatic compromise. The single most important reason that Prism is better than CAB is that you could easily, and
I do mean easily, roll your own Event Aggregator and replace the one in Prism while still using the rest of Prism. Hooray for “Composition over Inheritance.” You couldn’t do that with CAB.
Seek to help
Feb 23, 2012 at 5:23 PM
Thanks for your providing us with you feedback.
Based on my understanding, the EventAggregator class is basically a collection of events. The
Subscribe / Publish functionalities for each event are not implemented in the
EventAggregator class but in "event class" itself (that is, the type of the event's payload which should inherit from
EventBase). If you do not wish to retrieve the event from the
EventAggregator each time a Subscribe / Publish
operation needs to be performed, you could instead retrieve the event only once (through the
GetEvent method of the EventAggregator class), and store the event instead of the
EventAggregator. Like this you should be able to perform
Subscribe / Publish operations without requiring to perform the "get-the-event step."
Another possible approach could be to implement an extension method for the
IEventAggregator interface, which could be in charge of receiving the message to be published as a parameter and internally getting the event and publishing it. However, which approach would be more useful for you will depend mostly of your personal
preferences and the requirements of your scenario.
If you believe that the implementation of the event aggregation pattern in Prism should be changed, you can create a work item in the
Issue Tracker as a suggestion, so that the p&p team can consider it for future releases.