Question

I’ve been looking in to the Composite Application Library, and it’s great, but I’m having trouble deciding when to use the EventAggregator… or rather – when NOT to use it.

Looking at the StockTraderRI example, I’m even more confused. They are using the EventAggregator in some cases, and ‘classic’ events in other cases (in for example the IAccountPositionService interface).

I’ve already decided to use it for communication with a heavy work task, that should run on a background thread. In this case the EventAggregator offers marshalling of threads behind the scenes, so I don’t have to worry much about that. Besides that I like the decoupling this approach offers.

So my question is: When I’ve started using the EventAggregator in my application, why not use it for all custom events?

Answer 1

This is a good question. In Composite WPF (Prism) there are 3 possible ways to communicate between parts of your app. One way is to use Commanding, which is used only to pass UI-triggered actions down the road to the actual code implementing that action. Another way is to use Shared Services, where multiple parts hold a reference to the same Service (Singleton) and they handle various events on that service in the classical way. For disconnected and asynchronous communication, as you already stated, the best way is to use the Event Aggregator (which follows closely Martin Fowler’s pattern).

Now, when to and not to use it:

1. Use it when you need to communicate between modules. (for example, a Task module needs to be notified when a Task is created by any other module).
2. Use it when you have multiple possible receivers or sources of the same event. For example, you have a list of objects and you want to refresh it whenever an object of that type is saved or created. Instead of holding references to all open edit/create screens, you just subscribe to this specific event.
3. Don’t use it when you only have to subscribe to normal events in the Model View Presenter area. For example, if your presenter listens to changes in the Model (for example the Model implements INotifyPropertyChanged) and your Presenter needs to react on such changes, it’s better that your Presenter handles directly the PropertyChanged event of the Model instead of diverting such events through the Event Aggregator. So, if both the sender and receiver are in the same unit, there’s no need to ‘broadcast’ such events to the whole application.

I hope this answers your question.