Interaction of view models in MVVM

Question

I have a WPF application which follows the MVVM pattern. The application defines two views and view models so far:

• LoginView(Model)
• ProjectsView(Model)

Both view models need to access several properties from other view models.

Example:
LoginViewModel has a property ProjectList. ProjectsViewModel needs to access this property as well.

This is only a simple example. Later there will be several UserControls which all need to interact with each other.

Would it be a better idea to create one huge view model which all UserControls (views) set as their DataContext? If not, how can all the different view models interact with each other?

Remark:
This question is closely related to this one but with a different approach.

Answer 1

Usually I do one of 4 things:

• Make my ViewModels reference each other, and pass the property around. For example, LoginViewModel might set ProjectsViewModel.ProjectList on successful login. How you implement this depends on how your ViewModels are related to each other, and where logical points of connection would be.

• Make an ApplicationViewModel which manages things like which page is current, and application-wide objects like the current user or current project list. It would handle transferring shared data to the ViewModels that needs it.

• Use some kind of Event system to broadcast a message anytime an application-wide property changes, and have any ViewModel that's interested subscribe to receive those messages. The message typically contains the new object as well, so anyone subscribed to receive that message type has access to the new object. (I have a brief summary of Event Systems in my blog article Communication between ViewModels with MVVM if you're interested)

• Depending on if any of the other options work better, I may consider creating a singleton to hold application-wide data instead. For example, if the User is set on Login and is accessed from many of my ViewModels, I may create a singleton to set the user on first login, and then all my ViewModels can access it.

The one thing I would not do is make one big ViewModel holding all available data. ViewModels should only contain the data specific to it.

Answer 2

If you are using some sort of dependency injection tooling, you could inject a class that provides those values, for example, an IProjectService, that can return the list of projects on each of those view models.

The idea of one giant view model does not sound appealing, nor does strong coupling between view models by accessing each other's public properties. And if you want interaction between the view models, like when a project gets added, use a publish / subscribe model for each of the events you expect to occur.

Answer 3

Your Model should contain things like a project list, or give you the ability to access it. The ViewModel is simply meant to be a layer between the Model and View, giving you the chance to bring different Model objects together and mold them into a shape which the View can readily display and to handle commands from the View (modifying the Model in response).

Answer 4

Create one Base View Model keep all common Properties in that, Create singleton to BaseViewModel and add that singleton property in all View Models. All Viewmodels will get synced at one time.

Answer 5

You should definitely not make a huge "main view model" -- this is an anti-pattern not dissimilar to a god object.

The key idea here is that your viewmodels do not need to access several properties from other view models; rather, all of the viewmodels need to access specific pieces of information.

Right now you are most likely injecting this information into each viewmodel at the time of instantiation. Instead of doing this, provide each viewmodel with a reference to a service -- an application module that exposes this information through properties and/or methods. The information can be exposed in the form of scalar values if it's extremely simple in nature, or in the form of models if it's anything more complicated than that.

Schematically this would look like

/--------------\
|  ViewModelA  |
|              | <=======\
|              |         |
\--------------/         |  <--- information is pulled      /================\
                         +=========[model]===[model]======  |    Service     |
/--------------\         |                                  \================/
|  ViewModelB  |         |
|              | <=======/
|              |
\--------------/

The service should be injected into the viewmodels upon construction (either manually or by the DI container if you are using one). Each viewmodel should only require a reference to the service and enough information to tell to the service which model it's interested in; it will then request that model from the service and populate its "interesting" properties based on that.

This way of doing things is more involved than simply constructing a viewmodel object and setting its properties externally, but it will allow your application to grow in complexity without becoming unmanageable.

For example, if there are lots of views that bind on different viewmodels and these viewmodels depend in complex ways on a number of models, a sane manner to work would be:

1. A view/viewmodel pair is constructed
2. The viewmodel requests any models it needs to know about from the service; it subscribes to an event that the service exposes to let subscribers know that a model has changed
3. Changes are performed to the models through databound controls
4. The view invokes a "save" command on the viewmodel
5. In response to that, the viewmodel invokes a "save this model" method on the service
6. The service persists the information and publishes a "model changed" event (see step 2)
7. Other viewmodels interested in the same model know that the model has changed and can query the service for its new state

This is possible if everything is routed through the service. Imagine what it would take to keep everything synchronized otherwise -- the only way to cope would be to put all the information into a giant viewmodel and reference that from everything else. Ugly.