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. – Bart van Ingen Schenau Dec 30 '18 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 '18 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. – Bart van Ingen Schenau Dec 31 '18 at 9:15

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 '19 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 '19 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. – Blechdose Apr 22 '20 at 11:09

Your Answer

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

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