We have a wpf mvvm application with a lot of "panes". Just like the draggable panes in visual studio for example.

All of these are individual usercontrols with their own viewmodels and im trying to figure out how they should communicate with each other. For example: If i add an address in the address editor pane, the address overview pane should update itself. I think this is the perfect case for an event, just send out an "AddressAddedEvent" and let the overview handle it.

However, i can see this getting out of hand and leading to the control flow being really hard to follow. If another viewmodel uses a list of addresses that one needs to update itself too. So i add one address, raise one event, and end up calling like 13 methods in 13 viewmodels.

I never used the event aggregator pattern, does this happen? I tried to find negatives / cons, but nothing really came up.

When is it a bad idea to use the event aggregator pattern? Are there classic pitfalls to avoid? Can it be abused in some way by less experienced developers?

  • Prism does exactly what you describe. prismlibrary.com/docs/wpf/introduction.html – Robert Harvey Jun 14 '20 at 20:54
  • "Are there classic pitfalls to avoid? Can it be abused in some way by less experienced developers?" - basically, the events and their arguments form the interface between the communicating components. If you're not consciously endeavoring to keep the abstraction represented by that interface in check, you may end up with lots of subtle coupling and accidental complexity. So put some constraints on that, and adjust the events (conceptually rethink them) if you notice that they get in your way when you need to change things, instead of making the process easier. – Filip Milovanović Jun 14 '20 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.