Model-View-Controller (MVC)
MVC separates state, presentation and input responsibilities within a user interface.
- ModelProvides state and application data.
- ViewPresents state to people.
- ControllerTurns input into actions.
Context
Why this is important
Assign MVC roles when designing a user interface and check changes along the UI boundary.
A user-interface pattern: the roles interact differently across frameworks.
MVC roles in checkout
View, controller and model structure checkout; the seven shop modules retain their business boundaries.
This is how you read the picture
- Model State
- View Presentation
- Controller Input
| Criterion | Responsibility | Decision |
|---|---|---|
| Input action | Controller starts ordering flow. | UI responsibility |
| Error message | View presents result. | UI responsibility |
Benefits & limitations
Helps if:
- A user interface bundles presentation, state and input into a hard-to-change unit.
- Interface behavior can be tested and evolved by role.
Boundaries
- MVC is treated as a complete system architecture.
- Frameworks name roles differently or distribute them across runtime components.
In practice
- Trace a UI action from the View event to the rendered result and mark the Controller decision and Model change. Record the contract with the Ordering module that the interface actually needs.
- Check whether a change affects only presentation or input, or changes a business rule. Put business decisions in the responsible module and keep the Controller focused on flow coordination.
- Test input validation and presentation separately, then add a flow test for their integration. Ensure the View owns neither order rules nor database writes.
Read the detailed explanation
The model provides application state and behavior; the view presents it; the controller processes input and initiates actions. Frameworks vary the exact allocation.
MVC describes an interaction structure at the user interface. It defines neither a complete layered architecture nor business module boundaries.
The interface roles complement Layered Architecture and sit inside the business modules of the Modular Monolith.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which role handles “Place order”?
View the solution with justification
The controller.
ApplyingTransferred to a new situation
Where are validation errors shown to the customer?
View the solution with justification
The view presents the result returned by the workflow.
EvaluateWeighing an alternative
When does MVC alone provide insufficient boundaries?
View the solution with justification
When business module ownership and dependency direction must be decided.
Explore further
These building blocks continue the thoughts of this page.
References
- Krasner & Pope · Smalltalk-80 MVC (opens in new tab)Primary description of the MVC paradigm in Smalltalk-80.
- Microsoft · N-tier architecture style (opens in new tab)Explains layers and separation of responsibilities.
- Martin Fowler · Presentation Model (opens in new tab)Domain-oriented discussion of the presentation layer.