MVC pattern
Separate an application into Model (data and rules), View (display), and Controller (input handling) so each layer can change independently.
Introduction
MVC separates a user-facing application into three collaborating roles: the Model owns domain state and rules, the View renders that state, and the Controller translates input into model operations. The exact communication direction varies by framework, so treat MVC as a flow of responsibilities rather than a set of folders.
TL;DR / mental model
Think “input goes to the Controller, state changes in the Model, and the View renders the Model.” In the example below, the Model notifies the View through an Observer interface.
The Problem It Solves
You're building a task management app. The UI code fetches tasks from a database, formats them, validates input, and renders everything in one class. Every feature request touches the same file.
Three concrete problems. First, you cannot test validation logic without a database connection. Second, swapping from a console UI to a web UI means rewriting the entire class. Third, a designer changing the output format has to wade through SQL and input parsing code.
This is common in early-stage codebases: a single "app" class handles input, business rules, and rendering. It may ship quickly, but becomes harder to maintain as features accumulate.
Here is what changes when you apply the MVC pattern.
Core idea
Model owns the data and business rules. View renders the model's state. Controller translates user input into model operations. Each layer changes independently because they communicate through interfaces, not concrete implementations.
Structure
TodoModel is the single source of truth. It holds the todo list and notifies registered observers when anything changes. TodoView implements ModelObserver so it automatically re-renders when the model updates. TodoController receives raw user input, validates it, and calls model methods.
Implementation
Continue Reading with Premium
Unlock this article and every other in-depth system design guide on the platform with SDEpedia Premium.
Related Articles
The observer pattern decouples event producers from consumers. A subject notifies all registered observers of state changes without knowing who they are or what they do.
The strategy pattern extracts a family of algorithms behind an interface so the client can swap behaviors at runtime without touching the context class.
The facade pattern provides a single, simplified interface to a complex subsystem with many classes. Clients call one method instead of orchestrating five.