MVC / MVP / MVVM

The three roles they all share

Before the differences, the common skeleton. Every one of the three has these three parts:

• Model — the data plus the rules that protect it (a temperature, a user, a shopping cart, and the logic that says what's valid). It is passive about the UI: it never imports a button, never draws a pixel. It just holds truth.
• View — everything the user sees and touches: labels, text fields, buttons. Its job is to display and to capture raw input. How much thinking it's allowed to do is exactly what separates the three patterns.
• The middle coordinator — the piece that connects the two so they never touch directly. This is the Controller, the Presenter, or the ViewModel. Renaming this box and rewiring its arrows is the entire difference between MVC, MVP, and MVVM.

MVC — the Controller takes input, the View reads the Model

Model-View-Controller is the classic, and the oldest (Smalltalk, 1979). The flow: the user acts on the View, the Controller receives that input, decides what it means, and updates the Model. The Model changes, and the View reads the Model to redraw itself. The key move is that the View is allowed to look at the Model directly — it pulls the data it needs. The Controller is mostly a router for input.

class TempModel { celsius = 20; }                 // data + rules

class TempController {
  constructor(private model: TempModel) {}
  onPlusClicked() { this.model.celsius += 1; }    // input → update Model
}

class TempView {
  constructor(private model: TempModel) {}
  render() { return `${this.model.celsius}°C`; }  // View READS the Model itself
}

This is what server frameworks give you — Rails, Django, Spring MVC, Laravel, ASP.NET MVC. A request hits a controller action, the action touches the model, and a template (the view) renders from that model. It fits the request/response web perfectly: each click is a fresh round trip.

MVP — the Presenter does everything, the View is passive

Model-View-Presenter makes the View as dumb as possible. The View captures a click and immediately forwards it: presenter.onPlusClicked(). It contains no logic — it doesn't read the Model, doesn't format anything, doesn't decide anything. The Presenter holds all of that. It updates the Model, formats the result, and pushes the finished value back to the View by calling methods on a small View interface like view.showTemperature("21°C").

interface TempView {                      // the ONLY door the Presenter uses
  showTemperature(text: string): void;
}

class TempPresenter {
  constructor(private model: TempModel, private view: TempView) {}
  onPlusClicked() {
    this.model.celsius += 1;               // update the Model
    this.view.showTemperature(`${this.model.celsius}°C`); // PUSH result to View
  }
}

MVVM — data binding syncs the View and ViewModel for you

Model-View-ViewModel removes the manual push entirely. The ViewModel exposes bindable state — an observable temperatureText property. The View declares, once, that its label is bound to that property. From then on, two-way data binding keeps them in sync automatically: change the ViewModel and the label updates itself; type in a bound text field and the ViewModel updates itself. You write no glue code to copy values back and forth — the framework does it.

class TempViewModel {
  private model = new TempModel();
  temperatureText = observable(`${this.model.celsius}°C`); // bindable state

  increment() {
    this.model.celsius += 1;
    this.temperatureText.set(`${this.model.celsius}°C`);   // binding auto-updates the View
  }
}
// In the view template:  <label text="{bind temperatureText}" />  ← no push code

This is the modern default because frameworks ship the binding engine: WPF/XAML (where MVVM was coined), Angular, Vue, Knockout, SwiftUI, and Jetpack Compose. You describe what the UI should reflect, not when to update it.

A quick side-by-side

• Who's the middleman? MVC → Controller · MVP → Presenter · MVVM → ViewModel.
• How does the View get updated? MVC → it reads the Model · MVP → the Presenter pushes to it via an interface · MVVM → data binding updates it automatically.
• How smart is the View? MVC → medium (reads Model, some logic) · MVP → dumb (pure interface) · MVVM → declarative (just bindings).
• Coupling of View↔coordinator? MVC → Controller doesn't reference the View much · MVP → Presenter holds a View interface reference · MVVM → ViewModel doesn't even know the View exists (it just exposes observable state).
• Where you meet it: MVC → Rails, Django, Spring · MVP → old Android, WinForms · MVVM → WPF, Angular, Vue, SwiftUI, Compose.

Reach for...

• MVC — when you're building a server-rendered, request/response app. Each click is a round trip: controller handles the request, touches the model, renders a template. Rails, Django, Spring, Laravel, and ASP.NET MVC are all built around it.
• MVP — when the View must be dumb and unit-tested. If you need to verify presentation logic without spinning up a screen (a fake view interface in a test), MVP's passive View is exactly the shape you want. Classic for legacy Android and desktop WinForms/GWT.
• MVVM — when your framework gives you data binding. If you're in WPF, Angular, Vue, SwiftUI, or Jetpack Compose, lean into the ViewModel and let bindings erase the glue code. Fighting the binding engine to do MVP by hand is wasted effort.

Which to pick / skip when...

• The app is tiny — a one-screen toy doesn't need any of them. A Model plus a click handler is fine; adding a Presenter is ceremony with no payoff. Reach for a pattern when logic grows.
• No binding engine? Don't fake MVVM. Two-way binding by hand is fiddly and leaky. Without framework support, MVP (explicit pushes) is usually cleaner and easier to follow than a homegrown binding layer.
• Don't mix the roles. The moment SQL or business rules leak into the View, or the Model starts importing UI widgets, you've lost the [[separation-of-concerns]] that made you pick a pattern at all.