Back to Catalog
Software Design
architectural
Model-View-Controller (MVC)
Split your app into Model (data), View (UI), and Controller (logic in between) — each layer evolves independently without stepping on the others.
Intent & Description
🎯 Intent
Keep data, display, and user interaction logic in separate boxes so changing one doesn’t break the others.
📋 Context
You’re building a web, desktop, or mobile app where business logic and UI tend to get tangled together. Every new feature becomes a surgery because data access is mixed with rendering code.
💡 Solution
Split into three components:
- Model — owns the data and business rules, knows nothing about the UI.
- View — renders the UI, knows nothing about how data is fetched.
- Controller — handles user input, updates the Model, tells the View to refresh.
The Controller is the glue — it’s the only component that talks to both sides.
Real-world Use Case
Use when building apps with a clear separation needed between data and presentation — web apps, desktop UIs, or mobile apps where multiple views might share the same data.
📌 TL;DR
Model owns data. View owns UI. Controller owns the handshake between them. Parallel development becomes easy. Gets overkill fast on small projects.
Advantages
- Teams can work in parallel — backend devs own Models, frontend devs own Views.
- Business logic is centralized in Models, making it reusable across different Views.
- Clean separation makes unit testing each layer straightforward.
Disadvantages
- Adds structure overhead for simple apps — might be more architecture than the problem needs.
- Views and Controllers can creep toward tight coupling if the team isn’t disciplined.
Implementation Example
// Model
class Model {
constructor() { this.text = "Hello World"; }
}
// View
class View {
render(text) { console.log(`<h1>${text}</h1>`); }
}
// Controller
class Controller {
constructor(model, view) {
this.model = model;
this.view = view;
}
updateView() {
this.view.render(this.model.text);
}
}