Model–View–Controller Pattern
Model–View–Controller: separate a useful responsibility
See the responsibility boundary
A web page mixes request parsing, order rules, storage access and HTML construction in one block. Changes in presentation or business behaviour become hard to test and reason about separately.
This application-pattern lesson connects local organization with the system contracts discussed elsewhere in the course. The code is an original small local example, not a production persistence or web framework.
What you’ll learn
- Explain the responsibility Model–View–Controller separates.
- Follow its local example and identify the implementation boundary.
- Compare related patterns and test the required guarantees.
How the responsibility is divided
MVC separates a model’s data and domain behaviour, a view’s presentation, and a controller’s input/interaction coordination. Exact framework terminology differs, so follow the actual responsibilities rather than assuming every MVC framework has identical rules.
The local example has a model returning an order, a view formatting a response and a controller coordinating the operation. It is not a real HTTP server. In a web application, rendering must escape untrusted values and server-side permissions must protect the resource.
Follow a small JavaScript example
Read the program and compare the expected output. Its state is local to one execution context; a real implementation needs the persistence, request and effect contracts described in the trade-offs.
JavaScript · local teaching example
const model = {findOrder: () => ({id: 'O1', status: 'ready'})};
const view = order => 'Order ' + order.id + ': ' + order.status;
function controller() { return view(model.findOrder()); }
console.log(controller());Expected output
Order O1: readyChoose a boundary from the situation
Compare boundary choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
All alternatives and consequences remain visible. Select one per situation to record your reasoning.
Choose it for a concrete need
Use it where separating domain rules, presentation and interaction helps the application evolve. Keep the responsibilities aligned with the chosen framework’s lifecycle.
A controller can become a large business-rule container, while a passive model can scatter authority into presentation. MVC alone supplies neither access control nor distributed recovery. Define validation, authorization and escaping at their actual boundaries.
Compare the neighbouring responsibilities
Facade provides a focused subsystem operation and can support a controller. BFF shapes a client experience across a service boundary. MVC does not itself choose monolith or microservice deployment.
Continue with a focused subsystem operation, client-facing service interfaces, deployment boundaries independent of MVC.
For primary further reading, use the MVC catalog entry and compare the responsibilities with this course’s original example.
Check your pattern reasoning
Check your pattern reasoning
Keep the boundary and its guarantees explicit
Use Model–View–Controller when its responsibility matches the actual problem. Keep implementation lifetime, concurrency and error behaviour visible rather than treating an organizational label as proof.
Return to the design-pattern guide or apply this alongside deployment boundaries independent of MVC.
Reaching the recap and completing the quizzes are separate milestones.