Model–view–controller

MVC divides an application into three cooperating responsibilities. The model represents domain state and behavior, including validation, persistence, and business rules; the view renders information for a user or another presentation surface; and the controller interprets input, selects operations, and coordinates a response. The pattern does not require three isolated programs: they may be modules, classes, or framework conventions. Its central benefit is separation of concerns, which can let a change to a screen avoid changing domain logic and can let the same model support several views.¹

Data flow varies by implementation. A controller may update a model and choose a view, while the view observes model changes directly; in a web application, a request commonly enters a controller, which obtains model data and passes it to a template. The names describe responsibilities, not a universal call sequence.

MVC emerged in the Smalltalk environment at Xerox PARC, where it addressed the need to organize interactive graphical applications rather than merely web pages. Early Smalltalk descriptions treated the model as the application’s conceptual state, the view as a visual representation, and the controller as the interaction mechanism; the view and controller could work together around user events.¹ The influential 1988 paper by Glenn Krasner and Stephen Pope helped articulate the design for Smalltalk-80 and distinguished reusable interface machinery from application-specific models.

Later systems changed the emphasis. Cocoa documentation presents MVC as a way to assign responsibilities among objects, while web frameworks commonly merge or rename pieces: a template may serve as the view, a URL dispatcher may participate in controller work, and a model may combine domain and database concerns.²

Frameworks make MVC practical by supplying routing, rendering, data access, and lifecycle conventions. In Ruby on Rails, controllers handle web requests and coordinate models and views, while conventions reduce configuration; Django uses URL configuration, views, templates, and models, but its terminology does not map perfectly onto the classic three-part vocabulary.³⁴

MVC can improve unit testing by allowing domain behavior to be tested without a browser and presentation rendering to be tested with controlled data. It can also expose weaknesses: controllers may become oversized “fat controllers,” models may absorb unrelated infrastructure, and a view that contains substantial decision-making becomes difficult to test. Teams therefore often add services, repositories, presenters, view models, or application commands while retaining MVC as the broad organizing pattern.

MVC is not a rigid standard, and its lesser-known history explains why diagrams disagree. In some Smalltalk accounts, a view and its controller form a coordinated pair, with the controller handling device-specific interaction; in modern web systems, the browser is itself a significant view and client-side code may introduce another controller-like layer. Cocoa’s documentation also treats bindings and notifications as mechanisms that reduce direct coupling between model and view rather than as mandatory MVC elements.²

The pattern is consequently best judged by dependency direction and responsibility boundaries, not by labels. A command-line interface, mobile screen, JSON endpoint, and server-rendered page can all be views of related application capabilities, but they may require different controllers and serialization rules. MVC is also distinct from Model–view–viewmodel and Model–view–presenter, which move presentation state or interaction logic into additional abstractions.

Model

The component representing domain data, state, and rules.

View

A presentation component that displays model-derived information to a user or client.

Controller

A coordinator that interprets input or requests and directs application work.

Separation of concerns

An organization principle that assigns distinct responsibilities to distinct components.