Introduction
Model-View-Controller (MVC) is an architectural pattern that organizes an application into three interconnected layers: the Model, which holds data and business logic; the View, which renders presentation to the user; and the Controller, which mediates user input, updates the Model, and selects the appropriate View. Unlike the object-level patterns in this module, MVC operates at a larger architectural scale, coordinating whole subsystems rather than individual object collaborations.
Cricket analogy: In a franchise, the groundskeeper maintains the pitch data (Model), the broadcast graphics display the live score to viewers (View), and the third umpire interprets a review request and decides what replay to show next (Controller), each playing a distinct larger-scale role than a single fielding drill.
Explanation
The Model encapsulates application data and the business rules that operate on it; it is independent of how that data is displayed. The View is responsible purely for presentation, rendering the current state of the Model in a form the user can see, and it should contain minimal logic beyond formatting. The Controller receives user input (a button click, an HTTP request, a keystroke), translates it into operations on the Model, and then chooses which View should be rendered next, often by reading the updated Model state. Many implementations also wire the Model to notify Views of changes using an Observer-like mechanism, so that Views stay in sync without the Controller manually pushing updates to every View. Because MVC coordinates entire layers of an application rather than a single collaboration between a few objects, it is best understood as an architectural pattern applied at a broader scale than patterns like Observer, Strategy, or Command, even though it often uses those patterns internally.
Cricket analogy: The scoring database tracks runs and wickets independent of how it's shown (Model); the stadium jumbotron just formats that score for display (View); the umpire signals a boundary, updates the official scorebook, and decides the jumbotron shows a replay next (Controller) — and when the score updates, every display, from the jumbotron to the broadcast graphic, refreshes automatically like Observer-notified Views.
Example
class TaskModel:
"""Model: owns data and business logic."""
def __init__(self) -> None:
self._tasks: list[str] = []
def add_task(self, name: str) -> None:
if not name.strip():
raise ValueError("Task name cannot be empty")
self._tasks.append(name)
def get_tasks(self) -> list[str]:
return list(self._tasks)
class TaskView:
"""View: renders presentation only."""
def render(self, tasks: list[str]) -> None:
print("To-Do List")
for i, task in enumerate(tasks, start=1):
print(f" {i}. {task}")
class TaskController:
"""Controller: mediates input, updates model, selects/refreshes view."""
def __init__(self, model: TaskModel, view: TaskView) -> None:
self.model = model
self.view = view
def handle_add_task(self, name: str) -> None:
self.model.add_task(name)
self.view.render(self.model.get_tasks())
model = TaskModel()
view = TaskView()
controller = TaskController(model, view)
controller.handle_add_task("Write MVC notes")
controller.handle_add_task("Review pull request")Analysis
MVC's main benefit is separation of concerns: business logic (Model) can be tested independently of presentation (View), and multiple Views (web page, mobile screen, API response) can share the same Model without duplicating logic. The Controller keeps this separation clean by owning the mediation logic instead of letting the View talk directly to the Model in an unstructured way. The trade-off is added indirection and boilerplate for simple applications, and in practice many frameworks blur the boundaries (e.g., 'fat models' or 'view-controllers' in mobile frameworks). It is important to distinguish MVC from the object-level behavioral patterns covered earlier in this module: Observer, Strategy, and Command describe collaborations between a handful of objects, whereas MVC describes how an entire application's layers are organized, and it frequently uses Observer internally to keep Views synchronized with Model changes.
Cricket analogy: Separating the official scorebook (Model) from the stadium display (View) means analysts can test scoring logic offline, and the same match data can feed the jumbotron, TV broadcast, and mobile app without duplicating rules — but for a small local match, maintaining three separate score displays through a formal umpire-controller is overkill compared to one person just calling out the score.
Key Takeaways
- Model holds data and business logic, independent of presentation.
- View renders presentation based on the Model's current state.
- Controller mediates user input, updates the Model, and selects the View to display.
- MVC is an architectural pattern operating at a larger scale than object-level patterns like Observer or Strategy.
- Many MVC implementations use an Observer-like mechanism so Views stay synced with Model changes.
Practice what you learned
1. In MVC, which layer is responsible for holding data and business logic?
2. What is the primary responsibility of the Controller in MVC?
3. Why is MVC described as operating at a larger scale than patterns like Observer or Strategy?
4. How do Views commonly stay synchronized with Model changes in many MVC implementations?
5. What is a key benefit of separating Model and View in MVC?
Was this page helpful?
You May Also Like
Observer Pattern
A behavioral pattern where a subject maintains a list of observers and notifies them automatically of any state changes.
Software Architecture Basics
An introduction to software architecture: the high-level structure of a system, its components, and how they interact.
Monolith vs Microservices
Compares monolithic and microservices architectures across deployment, scaling, communication, complexity, and failure isolation.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics