WPF Prism EventAggregator: Subscribe, Publish and CompositePresentationEvent

WPF Prism EventAggregator: Subscribe, Publish and CompositePresentationEvent

EventAggregator is the integral part of Prism and is used to raise the events from one loosely coupled module to another using subscribe, publish and CompositePresentationEvent class.

PRISM is designed for large applications with lots of different teams working on different modules decoupled from each other. Prism is a complex concept and should never be used for small scale applications. To work with Prism, you should have knowledge about Commands, Message Bus, MVVM, Unity, MEF in order to get started with the framework.

You can download Prism from Microsoft Website.

For using EventAggregator, you need following DLLs from Prism

Microsoft.Practices.Composite.Events
Microsoft.Practices.Composite.Presentation.Events

What is Prism EventAggregator

As the name suggests, event aggregator in prism, aggregates or collects the events from various modules in the composite WPF application and make it accessible from various modules by subscribing and publishing the methods. In a composite application, the events are frequently shared between multiple modules, so they are defined in a common place.

In this way you can call methods of one module from another module. So by this approach, dependency between different moudules on an application decreases and they become loosely coupled.

CompositePresentationEvent class

CompositePresentationEvent class is a generic class that maintains the list of Subscribers and Publishers and connects them.

public class LoadEvent : CompositePresentationEvent<string>{}

Subscribe Events

For subscribing, you should mention a callback method which will be invoked.

eventAggregator.GetEvent<LoadEvent>().Subscribe(MyMethod);

Publish Events

Publishers raise an event by retrieving the event from the EventAggregator and calling the Publish method.

eventAggregator.GetEvent<LoadEvent>().Publish(“StringParameter”);

Unsubscribe Events

If your subscriber no longer wants to receive events, you can unsubscribe by using your subscriber's handler or you can unsubscribe by using a subscription token.

Subscribing Using Strong References

If you are raising multiple events in a short period of time and have noticed performance concerns with them, you may need to subscribe with strong delegate references—and therefore manually unsubscribe from the event when disposing the subscriber—instead of the default weak delegate references maintained by CompositePresentationEvent.

By default, CompositePresentationEvent maintains a weak delegate reference to the subscriber's handler and filter on subscription. This means the reference that CompositePresentationEvent holds to the subscriber will not prevent garbage collection of the subscriber. Using a weak delegate reference relieves the subscriber from the need to unsubscribe to enable proper garbage collection. However, maintaining this weak delegate reference is slower than a corresponding strong delegate reference. For most applications, this performance will not be noticeable, but if your application publishes a large number of events in a short period of time, you may need to use strong delegate references with CompositePresentationEvent to achieve reasonable performance. If you do use strong delegate references, your subscriber should unsubscribe to enable proper garbage collection of your subscribing object when it is no longer used.

Advantages of EventAggregators

1. Ease of adding new features.
2. Strong typing allows publishers and subscribers for a particular event to be quickly determined.
3. Event filtering means a subscriber that is not interested in every instance can ignore those it is uninterested in. Also the filtering is done in the Event Aggregator.
4. Fine grain control of what thread the processing should take place.
5. A central place for instrumentation.

Disadvantages of EventAggregators

1. Registration: Having listeners do the registration adds repetitive code to each listener.
2. Discoverability/Traceability: Event aggregation is a form of indirection, which makes the system harder to understand.
3. Serious memory leak issues since the EventAggregator maintains references to subscribers.
4. Does not support Event Latching, meaning cannot ignore events at times, and then support updates.
5. Event ordering is not guaranteed.
6. Getting the event through the GetEvent<T>() method to publish or subscribe is considered a bit clunky.