The Model-View-Controller (MVC) pattern
Pattern · Chapter 7
Overview
Section titled “Overview”- A widely used pattern for an application’s UI, especially well suited to web apps (also usable for desktop).
- Provides structure for building UIs and separates responsibilities.
- Frameworks that use it: Ruby on Rails, ASP.NET MVC, Spring MVC.
Components
Section titled “Components”| Component | Responsibility |
|---|---|
| Model | Manages application data and state; reads/writes to the data store. Independent of controllers and views → reusable and independently testable. Receives directives from controllers; provides state updates (passive = must be asked; active = pushes change notifications to views). |
| View | Presents the application; the part users see. Renders data from the controller (and possibly from model state notifications). Relays user input/actions to a controller. |
| Controller | Intermediary between model and view. Requests routed to it by routing config. Runs application logic, selects the view, feeds it what it needs, updates the model based on user actions. |
Advantages
Section titled “Advantages”- Separation of concerns: change presentation or data with less impact on the other; each part easier to test. (Full separation is hard — e.g. a new field touches both data and presentation.)
- More reusable presentation objects; a model can serve multiple views.
- Lets developers specialize (frontend vs backend) and work in parallel.
Disadvantages
Section titled “Disadvantages”- If the team isn’t split frontend/backend, developers must be full-stack (skilled in both, across multiple technologies).
- A very active model pushing notifications to views can cause excessive view updates on frequent model changes.
Related
Section titled “Related”Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.7 “The Model-View-Controller pattern”, pp. 537-542.