Introduction

In WPF MVVM, the ViewModel often needs to know when model data changes. The important constraint is that the Model should publish changes in a neutral way, not become aware of a specific ViewModel or screen.

Keep model notifications UI-agnostic

The Model owns domain state. The ViewModel reshapes that state for data binding, commands, labels, and validation messages. If the Model starts calling ViewModel methods directly, the boundary is broken and the domain layer becomes tied to presentation code.

That is why the usual answer is not "have the Model alert the ViewModel by name." The better answer is "let the Model expose change notifications, and let the ViewModel subscribe."

In small and medium WPF applications, INotifyPropertyChanged is the most common fit. It is simple, well understood, and works naturally with bindings and derived ViewModel properties.

1using System.ComponentModel;
2using System.Runtime.CompilerServices;
3
4public class CustomerModel : INotifyPropertyChanged
5{
6    private string _firstName = "";
7    private string _lastName = "";
8
9    public string FirstName
10    {
11        get => _firstName;
12        set
13        {
14            if (_firstName == value) return;
15            _firstName = value;
16            OnPropertyChanged();
17        }
18    }
19
20    public string LastName
21    {
22        get => _lastName;
23        set
24        {
25            if (_lastName == value) return;
26            _lastName = value;
27            OnPropertyChanged();
28        }
29    }
30
31    public event PropertyChangedEventHandler? PropertyChanged;
32
33    protected void OnPropertyChanged([CallerMemberName] string? name = null)
34    {
35        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
36    }
37}
38
39public class CustomerViewModel : INotifyPropertyChanged
40{
41    private readonly CustomerModel _model;
42
43    public CustomerViewModel(CustomerModel model)
44    {
45        _model = model;
46        _model.PropertyChanged += (_, e) =>
47        {
48            if (e.PropertyName == nameof(CustomerModel.FirstName) ||
49                e.PropertyName == nameof(CustomerModel.LastName))
50            {
51                PropertyChanged?.Invoke(
52                    this,
53                    new PropertyChangedEventArgs(nameof(FullName))
54                );
55            }
56        };
57    }
58
59    public string FullName => $"{_model.FirstName} {_model.LastName}".Trim();
60
61    public event PropertyChangedEventHandler? PropertyChanged;
62}

The Model stays reusable because it only raises a standard .NET change event. The ViewModel decides that FullName must be refreshed when either name changes.

When not to put notifications in the model

Some teams keep domain models plain and free of UI-facing interfaces. That can be the right choice when the same model types are shared by background jobs, APIs, or persistence layers. In that design, a repository, service, or domain event source may be a better place to publish changes.

The main principle does not change. The ViewModel listens to a neutral source of truth, then raises its own binding notifications. It should not force the Model to know about WPF-specific display concerns like colors, formatted labels, or command enablement.

One more practical detail matters in larger screens: event lifetime. If a long-lived model holds a strong event subscription to a short-lived ViewModel, you can accidentally keep objects alive. When ownership is unclear, use explicit unsubscription or a weak event pattern.

Common Pitfalls

• Giving the Model a reference to a specific ViewModel. That creates tight coupling and weakens reuse.
• Putting presentation logic in the Model just to simplify binding. Formatting and command state belong in the ViewModel.
• Forgetting to raise ViewModel notifications for derived properties such as FullName.
• Assuming every domain model must implement INotifyPropertyChanged, even when a service or domain event is a cleaner source of updates.
• Ignoring subscription lifetime, which can lead to memory leaks in long-running WPF views.

Summary

• The ViewModel should react to model changes without the Model knowing about a specific ViewModel.
• 'INotifyPropertyChanged is a common and valid way to expose model updates.'
• The ViewModel should translate those updates into UI-facing properties and commands.
• If the model layer should stay plain, publish changes through a service or domain event instead.
• Keep presentation concerns in the ViewModel so the Model remains focused on business state.