This content originally appeared on DEV Community and was authored by Dimension AI Technologies
MVC vs MVVM: Understanding Flow vs Roles
Many developers find MVC intuitive but MVVM opaque, yet also hear that MVVM is superior to MVC.
A key reason for this dissonance is that the acronyms MVC and MVVM list roles, not the runtime order (or pipeline) of input and updates.
An alternative mental model: ICMV and IVVMM
MVC (roles vs flow)
- Roles (name): Model – View – Controller
- Actual flow: Input → Controller → Model → View
- Instead of MVC, think of this as ICMV for the order of flow
MVVM (roles vs flow)
- Roles (name): Model – View – ViewModel
- Actual flow: Input → View
ViewModel Model - The flows are managed automatically with “data binding”
- Instead of MVVM, think of this as IVVMM.
To resolve the mismatch between the names MVC/MVVM and the order data flows, thinking of them instead as ICMV and IVVMM can help dramatically.
A very simple example of updating a name in a GUI follows:
Minimal MVC
Controller updates the model, then pushes data to the view.
// Model
public class Person { public string Name { get; set; } }
// View
public class PersonView
{
public void Show(string name) => Console.WriteLine($"Name: {name}");
}
// Controller
public class PersonController
{
private readonly Person _model;
private readonly PersonView _view;
public PersonController(Person model, PersonView view)
{
_model = model;
_view = view;
}
public void SetName(string name) => _model.Name = name;
public void UpdateView() => _view.Show(_model.Name);
}
// Usage
class Program
{
static void Main()
{
var model = new Person();
var view = new PersonView();
var controller = new PersonController(model, view);
controller.SetName("Alice");
controller.UpdateView(); // Output: Name: Alice
}
}
Notice: the controller orchestrates; the view is passive.
Minimal MVVM (using Microsoft WPF GUI)
The View binds to properties on the ViewModel; changes propagate via INotifyPropertyChanged.
ViewModel + Model (C#):
using System.ComponentModel;
using System.Runtime.CompilerServices;
public class Person { public string Name { get; set; } = ""; }
public class PersonViewModel : INotifyPropertyChanged
{
private readonly Person _model;
private string _name;
public PersonViewModel(Person model)
{
_model = model;
_name = model.Name;
}
public string Name
{
get => _name;
set
{
if (_name == value) return;
_name = value;
_model.Name = value; // keep model in sync
OnPropertyChanged();
}
}
public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged([CallerMemberName] string p = null)
=> PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(p));
}
View (XAML):
<Window x:Class="Demo.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MVVM Demo" Height="120" Width="280">
<StackPanel Margin="12">
<TextBlock Text="Name:" Margin="0,0,0,6"/>
<TextBox Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
<TextBlock Text="{Binding Name}" Margin="0,8,0,0"/>
</StackPanel>
</Window>
Window code-behind (DataContext once):
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
DataContext = new PersonViewModel(new Person { Name = "Alice" });
}
}
Notice: the view binds to Name. Typing updates the ViewModel (and model). When the ViewModel raises PropertyChanged, the UI refreshes automatically. No explicit controller call.
Takeaways
- MVC: Controller drives the sequence; View updates last.
- MVVM: binding keeps View and ViewModel in sync; changes flow both ways.
The acronyms describe parts, not order.
Thinking of them as ICMV vs IVVMM clears the fog by making the order explicit.
This content originally appeared on DEV Community and was authored by Dimension AI Technologies