Model-View-Controller (MVC) — input, update, render
The Model-View-Controller pattern on an interactive canvas: how user input reaches the controller, updates the model, and renders through the view.
MVC separates an application into three parts with one rule: the controller handles input, the model owns the state and rules, and the view renders the model — and neither the view nor the controller touches state directly.
Model-View-Controller (MVC) — input, update, render
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Follow the loop in the order the arrows draw it: user to controller to model to view and back to the user.
- The three columns are the three acts: input arrives, state updates, output renders.
- The lanes are the separation of concerns — each lane owns one kind of work, and no lane does another's.
Input
"User interacts with the interface" starts the loop, and "Controller receives the input" is the traffic cop: it reads the action, decides what it means and instructs the model. The controller's comment makes the rule explicit — it holds no state itself, which is why it can handle many requests without remembering anything.
Update
"Controller updates the model" crosses into the model's lane, and "Model holds the state and business rules" is the model's definition: it is the single source of truth for data and the rules that govern it. "Model notifies observers of the change" is the notification half — the model does not tell the view what to draw, it only announces that something changed, and any number of views can listen.
Render
"View re-renders from the model" is the view's only job: read the model and display it. Its comment notes the discipline that keeps MVC from collapsing — the view never changes data, it only asks and displays. "User sees the updated interface" closes the circle back in the user's row, which is where every interaction both begins and ends.
Key relationships and takeaways
- The controller handles input; the model owns state; the view renders — three responsibilities, three lanes.
- Neither the view nor the controller writes data; all changes flow through the model.
- The model notifies observers rather than commanding the view, so one model can drive many views.
- The separation makes each part testable alone — the pattern's original payoff.
- MVC is the ancestor of many modern patterns (MVVM, MVP, Redux-style stores), all preserving the same separation.
When to use this visual
- Introducing the pattern to a developer before they read a framework's docs — the triangle is the map every framework implements.
- Explaining why a codebase is hard to change: state handled in the view is an MVC violation, and it is visible on the canvas.
- Comparing MVC with the layered architectures in the clean architecture visual.
How it works
Map your framework onto the triangle
Rename the three boxes with your actual framework's pieces — a routes file as the controller, your ORM models as the model, your templates as the view — so the pattern is concrete.
Add the router step
Insert a routing step between the user and the controller if your framework has one, connected to the controller it dispatches to.
Show multiple views
Add a second view box both listening to the same model — a list and a detail view — to demonstrate the observer relationship the pattern relies on.
Add the persistence layer
Extend the model with a database step, noting that the model owns it and the controller and view never touch it directly.
Frequently asked questions
What is MVC?
MVC — Model-View-Controller — is a software pattern that separates an application into three parts: the controller handles input, the model owns the data and business rules, and the view renders the model. The separation's benefit is that each part can be developed and tested independently, and the same model can be shown by many views. It is the pattern most web frameworks are built on.
Why is the model the centre of MVC?
Because the model is the single source of truth. If both the controller and the view could write data, they would drift and fight over state. Keeping all changes in the model means there is exactly one place where data rules live, and the view is always a projection of a consistent model. The visual places both model boxes in their own lane for this reason.
What happens if I put logic in the view?
You get an anti-pattern sometimes called the "fat view": display code mixed with business rules, which cannot be tested without rendering, and which drifts from the model. The same criticism applies to a controller that holds business logic instead of delegating. MVC's discipline is that each lane stays in its lane — the visual's three separate rows are the rule made visible.
How does MVC relate to modern frameworks?
Most modern frameworks preserve the triangle with new names: MVVM adds a view-model layer, MVP gives the view a presenter, and state-management libraries like Redux are essentially the model with a stricter notification rule. The canvas's core loop — input changes state, state drives output — is the invariant every one of them keeps.
Edit this visual in QueryChart (FlowJam)
Open this exact MVC canvas as your own chart, rename the boxes to your framework, and trace your own request path.