Event aggregator for conditional actions

Question

I am involved in the development of a WPF Prism application which uses the event aggregator to send global type messages which are then picked up by the shell. For example, a viewmodel might want a toast message displayed but doesn't really care how it is displayed. In this instance the shell would be setup to process those events and act on them application wide.

The question I have is how do you do it if a particular view wants to display the toast messages differently. I like the global approach because it is very simple, but how to customize it for special cases?

Answer 1

I think this really depends upon how your application is setup and what standards/patterns you are using. In MVVM I see two approaches.

View-First
If your View-Model is injected into your view, then send the messages to your view, and let the View decide what to do with it. If it wants to display them itself, it can do that. If it wants to send them to your shell, it can do that through the event aggregator or injecting a Toast service interface. That keeps your View in control of the visual.

View-Model-First
If your View is injected into your View-Model, then your View Model should be asking for a different View, which should be bound to its own View Model. If it wants to send messages to another View-Model, it can do that through the event aggregator or injecting a Toast View-Model/service interface. That keeps your View-Model in control of the navigation between Views.

I prefer the View-First approach because it keeps your View in control of the visualization of your model. But I'm very interested in how other MVVM developers tackle this. This seems very closely aligned with the question of how to present dialogs in the MVVM View-First approach.

Answer 2

Using Eventaggregator for this purpose is not the right way I think, because the events are broadcasted to the entire application.

One possible way to handle the scenario is your viewmodels can get an IMessenger interface injected in the constructor. There is an application implementation of IMessenger(which is injected by default) and you can have customised implementations of IMessenger according to your needs. Your viewmodel just calls an interface function(say DisplayMessage()), but according to the Messenger injected to it, the behaviour is different.