Model View Controller

Model-View-Controller (MVC) is a software architectural pattern widely used in application design — separating an application's data (Model), user interface (View), and the logic connecting the two (Controller) into distinct components. Key benefits include modular design, separation of concerns, code reusability, simultaneous development, and better testability. See Software Architecture for the general discipline MVC is one specific pattern within.

The three components

• Model — represents the data and business logic of the application: data structure, storage, and operations related to the application's data. The Model manages data access, manipulation, and validation, operates independently of the user interface, and notifies the View and Controller of changes.
• View — the presentation layer: the user interface, responsible for displaying data to the user. In MVC, the View is passive and contains no application logic — it receives data from the Model and presents it.
• Controller — the intermediary between Model and View: handles user input, manipulates data in the Model, and updates the View accordingly. It receives input via the View, processes it, updates the Model, and listens for Model changes to update the View in turn.

Why separate these concerns

Keeping data, presentation, and coordination logic in distinct components means each can change independently — a new UI can be built against the same Model without touching business logic, the Model's validation rules can change without touching presentation code, and each piece can be tested in isolation rather than only as an entangled whole.

MVC and its many variants

Many frameworks implement variations on this pattern (MVVM, MVP, and others) with different divisions of responsibility, particularly around where the "connecting" logic lives and how directly the View can bind to the Model. When working in a specific framework, check which variant it actually implements rather than assuming textbook MVC — the boundaries between the three roles vary meaningfully across frameworks that all use the "MVC" name loosely.

Common pitfalls

• Business logic leaking into the View — a View that directly queries or manipulates data undermines the separation of concerns MVC is meant to provide.
• A "fat controller" — a Controller accumulating business logic that actually belongs in the Model turns it into an unstructured dumping ground, defeating the pattern's modularity benefit.
• Tight coupling between View and Model — a View that depends on Model internals directly, rather than through the Controller, reintroduces the entanglement MVC exists to avoid.
• Assuming every framework's "MVC" is the same — the pattern is implemented with real variation across frameworks and languages; verify a specific framework's actual conventions rather than assuming the textbook definition applies exactly.

Learn more

• Software Architecture for the general architecture discipline MVC is one pattern within.
• Domain Driven Design for a complementary approach to structuring the Model's business logic specifically.