How should multiple ViewModels communicate in a larger WPF MVVM application?

Question

I’m working on a WPF MVVM application that has grown beyond just one or two User Controls. I now have multiple ViewModels that need to react to each other’s actions (e.g., selecting a customer in one list should update a detail view and a related properties list).

I’m trying to keep the architecture clean, testable, and maintainable — without creating tight coupling between ViewModels.

From my research, I see several possible approaches:

---

1. Parent ViewModel as coordinator

A single “parent” ViewModel owns the child ViewModels and wires them together via events or method calls:

public class MainViewModel
{
    public CustomersListViewModel CustomersList { get; }
    public CustomerDetailViewModel CustomerDetail { get; }

    public MainViewModel(CustomersListViewModel list, CustomerDetailViewModel detail)
    {
        CustomersList = list;
        CustomerDetail = detail;

        CustomersList.CustomerSelected += async id => await CustomerDetail.LoadAsync(id);
    }
}

Pros: Simple, explicit, easy to test
Cons: The parent can become a “God object” if too much logic is centralized

---

2. Messenger / EventAggregator

Using IMessenger from CommunityToolkit.Mvvm or a similar event aggregator to decouple ViewModels:

public record CustomerSelectedMessage(Guid CustomerId);

public class CustomersListViewModel
{
    private readonly IMessenger _messenger;
    public CustomersListViewModel(IMessenger messenger) => _messenger = messenger;

    public void SelectCustomer(Guid id) =>
        _messenger.Send(new CustomerSelectedMessage(id));
}

public class CustomerDetailViewModel : IRecipient<CustomerSelectedMessage>
{
    public CustomerDetailViewModel(IMessenger messenger) => messenger.Register(this);

    public void Receive(CustomerSelectedMessage msg) =>
        LoadAsync(msg.CustomerId);
}

Pros: No direct references, easy to add more listeners later
Cons: Event flow can be harder to trace/debug

---

3. Shared service for state

A service holds shared state (e.g., currently selected customer):

public class SelectionService
{
    public Guid? SelectedCustomerId { get; set; }
}

public class CustomersListViewModel
{
    private readonly SelectionService _selection;
    public CustomersListViewModel(SelectionService selection) => _selection = selection;

    public void SelectCustomer(Guid id) => _selection.SelectedCustomerId = id;
}

public class CustomerDetailViewModel
{
    private readonly SelectionService _selection;
    public CustomerDetailViewModel(SelectionService selection) => _selection = selection;

    public async Task LoadFromSelectionAsync()
    {
        if (_selection.SelectedCustomerId is Guid id)
            await LoadAsync(id);
    }
}

Pros: Simple, especially for persistent/global state
Cons: Not event-driven — may require polling or additional events

---

Question:
For a medium-to-large WPF MVVM application, what is the most common and best practice approach for ViewModel-to-ViewModel communication?
Should I stick to one pattern or mix them depending on the scenario?

Answer 1

Option 0

A big view model. But not a parent view model

ie

public class MainPageVM
{
  public List<Customer> customers; //bind to CustomersList XAML
  public Customer selectedCustomer; //bind to CustomerDetail XAML AND CustomersList if it has highlighting etc for selected item
  public MainPageVM()
  {
    //binding really should be in the View but for brevity..
    CustomersList.CustomerSelected += async id => this.selectedCustomer = this.customers.First(i=>i.id == id);
  }
}

The problem you run into with the parent view model which this avoids is that of you creating non-generic Controls, each with their own view model. eg CustomerList.

CustomerList sits uncomfortably between a control and a page. You can still have it, but instead of exposing its code behind or viewmodel, just have bindings of the Model classes like List<Customer> customers and plain events like CustomerSelected

Hold all the state at the top and treat your User Controls like Controls rather than sub pages. This keeps your page viewmodels flat and the logic easy to follow.

Answer 2

My approach for a similar problem is probably somewhere between your option 1 and Ewan's answer. I have a "master" view model that represents the top-level view, and it contains references to child view models (corresponding to child objects of the top-level object in the model).

In your case, I think that would correspond to something like:

public class MainViewModel : INotifyPropertyChanged
{
    public ObservableCollection<CustomerDetailViewModel> Customers { get; }

    public MainViewModel(IEnumerable<Customer> customers)
    {
        Customers = new ObservableCollection<CustomerDetailViewModel>();
        foreach (var customer in customers)
        {
            Customers.Add(new CustomerViewModel(customer)); // Can have ref to this too
        }
        // etc.
    }

    // etc.
}

Then your view has some sort of container control, and it can have a data template to set up binding to properties on CustomerViewModel, and you can also have a Customer view with bindings on the same view model.

If you really need to, you could have the child view model have a back-reference to the main view model, but I think ideally most things would be represented through properties (and INotifyPropertyChanged) rather than explicitly-subscribed events.

ObservableCollection is better if you expect the collection to be changing while the view is open, but you could do some more basic IEnumerable or collection if it will be static.