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

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.