Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Patterns & Design Principles  ›  Lesson

MVC, MVP and MVVM

MVC, MVP, MVVM 15 minMVC, MVP and MVVM all separate data and rules from what is shown on screen, and differ in which part handles input and how the view gets updated.

MVC, MVP and MVVM

DabbaGo's kitchen dashboard started as one big file: it fetched orders, applied the "cannot mark ready before cooking starts" rule, and drew the buttons, all mixed together. When the company wanted a tablet version, nothing could be reused, and the rule could not be tested without clicking through the screen. Three classic patterns exist to prevent exactly this.

The rule

Keep the rules out of the screen; patterns differ in who handles input and updates the view.

All three patterns split a user interface into the same first two parts:

  • Model: the data and business rules. Orders, statuses, the rule about when an order may be marked ready. It knows nothing about screens.
  • View: what the user sees. Lists, buttons, colours.

They differ in the third part, the one in the middle.

MVC: Model, View, Controller. The controller receives user input, such as a click or a web request, and tells the model what to do. The view then displays the model's current state. In many web frameworks, a controller handles a request, updates the model, and picks a view to render the response.

MVP: Model, View, Presenter. The view is kept passive: it forwards user actions to the presenter and shows whatever it is told. The presenter talks to the model and then updates the view through a small interface, for example calling showOrders(list). Because the presenter only knows that interface, it can be tested with a fake view.

MVVM: Model, View, ViewModel. The view model exposes state (the order list) and commands (mark ready) that the view binds to. When the view model's state changes, the binding redraws the view automatically; nobody calls "update the screen" by hand. Frameworks with data binding make this natural.

MVC   input → Controller → Model;  View reads Model
MVP   input → View → Presenter → Model;  Presenter updates View
MVVM  View binds to ViewModel;  ViewModel talks to Model

The shortcut

Ask two questions of any UI design: "Who receives the input?" and "How does the view learn about changes?"

  • Controller receives it; view reads the model → MVC.
  • View passes it to a presenter; presenter pushes updates into the view → MVP.
  • View binds to state and commands; changes flow through binding → MVVM.
Classifying the kitchen dashboard rewriteStep 1 of 4

  1. Who receives the "mark ready" tap?

    The button is bound to a markReady command on a KitchenViewModel.

The trap is putting business rules in the middle part. A controller, presenter or view model that contains the ready rule is just a new place for it to hide. The middle part coordinates; the model decides.

Drills

Answer fast — trust the rule.

quick drill

In all three patterns, where should the rule "an order cannot be marked ready before cooking starts" live?

quick drill

A passive view forwards clicks to an object that then calls view.showOrders(list). Which pattern is this?

quick drill

The order list on screen redraws automatically when a property on the middle object changes. Which pattern is this?

quick drill

Why is the MVP presenter easy to unit test?

Remember

  • Model holds data and rules; view shows them; the middle part coordinates.
  • Shortcut: who receives the input, and how does the view learn about changes?
  • Trap: moving business rules into the controller, presenter or view model.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainWhich part does what?

DabbaGo's kitchen app shows today's orders and a 'mark as ready' button. Explain what the model, the view and the middle part would do in MVVM, and why keeping the model free of screen code helps.