Abstracting event aggregator

Topics: Prism v4 - WPF 4
Feb 15, 2011 at 2:42 PM

For communication between modules, the event aggregator mechanism is well suited.

However, I was wondering if it would be a good pattern to abstract this into a service, so that modules don't have to care about it, like for example putting the following ApplicationService in the Infrastructure project of a PRISM application:

    public class ApplicationService : IApplicationService
        private readonly IEventAggregator _eventAggregator;       

        public ApplicationService(IEventAggregator eventAggregator)
            _eventAggregator = eventAggregator;

        private int _currentPatientId;
        public int CurrentPatientId
            get { return _currentPatientId; }
                _currentPatientId = value;
        public void OnCurrentPatientIdChanged(Action<int> action)
            _eventAggregator.GetEvent<PatientChangedEvent>().Subscribe(action, ThreadOption.UIThread, true);

If one module wants to set the current patient, it uses the ApplicationService:

applicationService.CurrentPatientId = 5;

If another module wants to react on it:

applicationService.OnCurrentPatientIdChanged(patientId => { /** Do something **/ });

So the modules are still unaware of each other, they only have a reference to the Infrastructure project. But they use the ApplicationService in an easy way without having to worry about event aggregator.

Do you see problems with this approach?



Feb 15, 2011 at 4:45 PM


Based on my understanding, your approach doesn't seem to have any flaw that could pose a threat to your application design. The EventAggregator mechanism is useful to communicate between modules, but you don't necessarily have to use it directly. By abstracting it like you've done, you don't need to obtain a reference to the Event Aggregator on each module that needs to use it.

I hope you find this helpful.

Guido Leandro Maliandi