Can someone explain concretely why it is not desirable for ViewModels to communicate directly with other view models? It seems to me that for virtually any UX application there will be a “root” view (with its ViewModel) and any further views will be somehow initiated from from this view/ViewModel, or a sub view/viewModel.

The recommendation seems to be that any communication between ViewModels takes place via a message bus or event aggregator but I can’t help but think this is overkill. For example, say we have an application that lets users define different profiles and do other actions based on the current profile. In this example the main window is dependent on something handling the profile management. Obviously i don’t want to hard core the ProfileManagerViewModel as a dependent of the MainViewModel but it seems to me that simply creating an interface (e.g. IProfileManager) is isomorphic with sending a message over a bus or aggregator. And if these are isomorphic then the interface is much easier to implement and maintain.

Even if it’s not completely isomorphic, it strikes me as a YNGNI situation: in what scenarios will I gain something extra from using an event aggregator over an interface and how likely is my application to ever encounter these scenarios during its expected lifetime? I would expect the common case to be that if my interface must change somehow (whether my interface be a C# interface or an event that I use to signal) both ViewModels will require modification anyway.

So what am I missing here? The only case I can think of is if additional viewModels were interested in e.g. the ProfileManager from my example being started but I don’t expect this to be a common situation in most applications. Of course if one sees the use of event aggregators as not adding any complexity then this whole question probably doesn’t make much sense but I think most people would see a standard interface solution radically easier to follow and reason about.

  • 1
    What you might be missing is that most Views/ViewModels should communicate via the Model part of MVVM. Especially in situations like your example, where information (like the active profile) needs to be persisted. Dec 30, 2018 at 13:46
  • I’m not talking about ViewModel to Model communication as this part makes perfect sense to me. What isn’t as obvious is why ViewModel would have to communicate via message bus instead of an interface. I understand how I would persist the profiles: this would be between the ProfikeManagerViewModel and the Profiles. The question is how I go from clicking “manage profiles” in the main window to having that view open. I like viewModel based navigation (with DataTemplates to select the view) but I don’t see why all MVVM frameworks would have me involve an event aggregator.
    – Jason
    Dec 30, 2018 at 15:56
  • Then I completely misunderstood your question. The way I understood your question was that you wanted the main window to respond to changes made in the profile view without involving the Profile model. Perhaps you can edit your question to make it more clear that you are asking about instantiating a new View/ViewModel in response to a user action. Dec 31, 2018 at 9:15

1 Answer 1


Views and ViewModels are meant to be reuseable components that you can combine together in different ways.

If you hardcode a command on VM1 to always update VM2 then you break that reusuablity.

But this doesnt mean that you can't have a master view model which links all the components of a page together. Or sub view models which link a set of controls together.

That kind of linking is done outside of the VMs themselves and as such doesnt introduce any hard coupling between them.

  • In case someone says "But I don't care about reusability, I'm not going to reuse anything": ANY component should know as little as possible about any other component.
    – gnasher729
    Jan 1, 2019 at 18:11
  • I guess the essence of my question is why MVVM practice is to use a message bus for decoupling (which I realize is needed and said so in the question) instead of just interfaces. The view model has the dependency regardless of whether it is expressed via an injected interface or via some message sent over a bus. Both approaches are isomorphic as far as I can see.
    – Jason
    Jan 3, 2019 at 8:32
  • i dont think that reusability is a reason. I have never seen that a viewModel has been reused. they are to specialized.
    – Welcor
    Apr 22, 2020 at 11:09
  • @Welcor maybe that's exactly the problem? They are too specialized by mostly being either too big or not adjustable at all. I can think of quite a few cases to reuse a view-model and their views: a search control, a filter control, an item-control to display some items, a progress control.
    – t3chb0t
    Aug 27, 2023 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.