What Is MVVM?
MVVM stands for Model-View-ViewModel, an architectural pattern that splits an application into three collaborating layers: the Model holds data and business rules, the View renders the UI, and the ViewModel exposes the View's state as observable properties and translates user actions into commands. The defining trait of MVVM, compared to older patterns, is that the View and ViewModel communicate through a data-binding mechanism rather than direct method calls, so the ViewModel never holds a reference to a concrete View object.
Cricket analogy: Think of a TV cricket broadcast: the scoreboard graphic (the View) automatically updates the moment the umpire's decision engine (the ViewModel) changes the run count, with no producer manually typing numbers onto the screen after every ball.
The Three Layers
The Model is the lowest layer: plain data structures, domain entities, and business logic such as validation rules or persistence, with zero awareness of any UI. The View is the highest layer: buttons, lists, and layouts, defined declaratively in something like XAML, SwiftUI, or Jetpack Compose, and it knows nothing about business rules. The ViewModel sits between them, pulling data from the Model, shaping it into display-friendly, observable properties, and exposing commands the View can invoke, while remaining ignorant of any specific View implementation so the same ViewModel could theoretically drive more than one View.
Cricket analogy: The pitch and groundstaff records (Model) exist independently of any specific broadcast; the director's feed selection and graphics overlay (ViewModel) reshapes raw match data for the specific screen (View) the viewer sees, whether it's a phone app or stadium jumbotron.
Data Binding: The Glue
Data binding is the mechanism that keeps View and ViewModel synchronized without either side writing imperative glue code. In a two-way binding, when the ViewModel's property changes, a notification mechanism such as INotifyPropertyChanged in .NET, @Published combined with ObservableObject in SwiftUI, or LiveData/StateFlow in Jetpack Compose fires, and the framework automatically re-renders the bound UI element; conversely, when a user types into a text field, the bound ViewModel property updates immediately. This is what eliminates the manual 'read from UI, write to model, and vice versa' boilerplate that dominated earlier UI code.
Cricket analogy: DRS (Decision Review System) graphics update automatically the moment ball-tracking data changes, and a captain's review request immediately flips the on-screen status, exactly like two-way binding propagating changes in both directions between View and ViewModel.
// WPF-style MVVM using INotifyPropertyChanged
public class LoginViewModel : INotifyPropertyChanged
{
private string _username = string.Empty;
public string Username
{
get => _username;
set
{
_username = value;
OnPropertyChanged(nameof(Username));
OnPropertyChanged(nameof(CanLogin));
}
}
public bool CanLogin => !string.IsNullOrWhiteSpace(Username);
public event PropertyChangedEventHandler? PropertyChanged;
private void OnPropertyChanged(string name) =>
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}
<!-- XAML View binds directly to the ViewModel property -->
<TextBox Text="{Binding Username, UpdateSourceTrigger=PropertyChanged}" />
<Button Content="Log In" IsEnabled="{Binding CanLogin}" />MVVM was formally named and popularized by Microsoft architect John Gossman in 2005 to describe a pattern for building WPF and Silverlight applications, leveraging their built-in data-binding engines; it has since become the dominant pattern for SwiftUI, Jetpack Compose, and Angular applications, all of which ship first-class observable state and binding primitives.
Why Use MVVM?
MVVM's main payoff is testability: because the ViewModel exposes plain properties and commands with no dependency on a rendered View, you can unit test all of your presentation logic — validation, formatting, enabling and disabling buttons — without spinning up a UI framework or simulator. It also improves separation of concerns, letting designers iterate on the View's markup while developers work on ViewModel logic in parallel, and it supports reuse, since one ViewModel can back multiple View implementations, such as a phone layout and a tablet layout, as long as both bind to the same properties and commands.
Cricket analogy: A team's analytics unit can validate a bowler's economy-rate calculations against historical data entirely offline, without needing an actual match broadcast running, the same way a ViewModel's logic is unit-testable without a rendered UI.
A common anti-pattern is the 'Massive ViewModel,' where business logic that belongs in the Model — validation rules, calculations, persistence — gets stuffed into the ViewModel because it's convenient, producing a class that is technically UI-agnostic but is really just a bloated god-object; keep the ViewModel focused on shaping and exposing state, and push domain rules down into the Model.
- MVVM splits an app into Model (data/business logic), View (UI), and ViewModel (presentation state and commands).
- The View binds to the ViewModel through data binding, so the ViewModel never references a concrete View.
- Two-way binding synchronizes property changes in both directions without manual glue code.
- MVVM was popularized by John Gossman at Microsoft in 2005 for WPF and Silverlight.
- The ViewModel's independence from any View makes presentation logic straightforward to unit test.
- One ViewModel can drive multiple Views, enabling reuse across form factors.
- Avoid the 'Massive ViewModel' anti-pattern by keeping domain logic in the Model, not the ViewModel.
Practice what you learned
1. What mechanism keeps the View and ViewModel synchronized in MVVM without manual glue code?
2. Which layer in MVVM should never hold a reference to a concrete View implementation?
3. Who is credited with formally naming and popularizing the MVVM pattern?
4. Why is the ViewModel in MVVM generally easy to unit test?
5. What is the 'Massive ViewModel' anti-pattern?
Was this page helpful?
You May Also Like
MVVM vs MVC vs MVP
A comparison of how MVC, MVP, and MVVM each connect the middle layer to the View, and when to choose each.
The Model in MVVM
What belongs in the Model layer of MVVM, how it differs from ViewModel state, and how to test it.
The View in MVVM
The View's role as a declarative, logic-free rendering layer that binds to the ViewModel and forwards user input.
The ViewModel in MVVM
How the ViewModel exposes observable state and commands, manages lifecycle, and stays independently testable.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics