Glossary

MVC

Model, View, and Controller divide responsibilities at the user interface. MVC does not, however, prescribe an application’s entire architecture or the directory in which every class must live.

Short definition

Input, application state, and output should not collapse into one place.

The Model represents the data, state, and rules with which the interface works. The View turns a result into a form suitable for a user or client, while the Controller responds to input, initiates the required work, and coordinates creation of the response. Web frameworks interpret the collaboration between these roles differently, but separation of responsibilities remains the underlying aim.

In a server-side web application, MVC commonly sits alongside a router, application services, a domain model, a database, and a framework. These are not automatically additional parts of MVC. The pattern primarily organises the path from user input through the application model to the final presentation.

What it solves

Changing a screen should not mean rewriting the rules of an order.

Without clear responsibilities, it is easy to end up with one controller or script that reads the request, assembles SQL, makes business decisions, and generates HTML. Code like this is difficult to test and change.

separating HTTP input handling from application rules and state
using the same application operation from an HTML page, JSON API, or console command
changing presentation independently without moving business decisions into the template
small controllers that coordinate one use case rather than running the entire application
clear locations for input validation, authorisation, data loading, and response construction

Practical example

An order detail page in a PHP application

A GET /orders/1042 request first reaches the router, which selects OrderDetailController. The controller receives the identifier 1042 and the user context, validates the input format, and calls an application service that retrieves the order view. It should not contain the SQL query, permission calculation, currency conversion, or order-state rules itself.

The application service loads the required model, enforces authorisation, and returns output data. For a server-rendered page, the View can pass this data to an HTML template. In a JSON API, the presentation role may belong to a responder or serializer that produces stable JSON and the correct HTTP status; a View is therefore not necessarily just an HTML file.

Text flow diagram and accessible alternative

HTTP Request
  → Router
  → Controller
  → Application / Domain (Model)
  → View or JSON responder
  → HTTP Response

How it works

From an HTTP request to a response

This flow is the text alternative to the diagram. Exact class names are not part of the pattern and may differ between Symfony, Laravel, Nette, and a bespoke implementation.

The router selects a controller It finds the relevant entry point from the URL and HTTP method. Routing is framework infrastructure, not a mandatory fourth part of MVC.
The controller accepts input It obtains the order identifier and user context, translates the technical request into application input, and decides how to respond to the result.
The Application and Model do the work An application service coordinates the use case and the model protects its data and rules. A repository or another data adapter may provide database access.
The controller selects the presentation It can pass a successful result to an HTML template, JSON responder, or another form of View; it turns an error into the appropriate status and output.
The View creates the response The presentation layer formats data for the client. It should not decide again whether the user may view the order or whether its state is valid.

Key components

Three roles whose boundaries adapt to the interface in practice.

MVC does not say that each part must be represented by exactly one class. The Model may comprise several objects and services, the View may include a presenter and template, and applications typically have multiple controllers for individual actions.

Model

It holds meaningful application data, state, and rules. It may include domain objects, application services, query models, or data access. The Model is not automatically a Doctrine Entity or a simple copy of a database table.

View

It presents data in a form suitable for the client. This may be an HTML template, a server-side component, a JSON representation, or another output; material business decisions do not belong here.

Controller

It reacts to input, prepares arguments for an application operation, and selects the resulting response. A controller may perform straightforward coordination, but accumulating business logic creates a “fat controller” that is hard to test.

Separation of responsibilities

These boundaries reduce the impact of changing the output format, HTTP details, or data-loading mechanism. Poorly chosen abstractions, however, can merely lengthen a request’s path without providing genuine separation.

HTML and APIs

An API still needs input handling, an application model, and a representation of the result, but may use neither a template nor exactly the same interpretation of View as a traditional server-rendered website. Clear responsibilities matter more than the label.

Benefits and limitations

Separation helps only when the boundaries remain meaningful.

Benefits

presentation changes have less impact on application rules
the controller can be tested as a thin coordinator and the model independently against its scenarios
the same operation can be exposed through HTML and JSON without duplicating business logic
responsibilities are clearer to the team than in one universal request handler

Limitations and common mistakes

equating the Model with one ORM entity or the entire persistence layer
putting authorisation, SQL, and every rule into the controller
loading data and changing its state directly from an HTML template
copying a framework’s directory structure and treating it as proof of MVC
creating a presenter, mapper, and DTO for trivial output when they separate no genuine source of change

Relationship to application architecture

MVC addresses the user interface, not every boundary in a system.

MVC is not the same as three-tier architecture. A three-tier design generally distinguishes the presentation, application, and data tiers; MVC describes collaboration between the Model, View, and Controller around input and presentation. The concepts may overlap in a particular application, but they cannot be mechanically mapped one-to-one.

Clean Architecture and Domain-Driven Design answer different questions. Clean Architecture concerns dependency direction, DDD the meaning of the domain and model boundaries, while MVC organises the interface. A PHP application can therefore use MVC at its HTTP edge while also having application and domain boundaries inside.

A controller that calls a single application service directly may be enough for a small CRUD screen. A complex order process needs a richer model and testable use cases, but additional layers should arise from concrete complexity rather than the name of a pattern.

What to consider

The Controller coordinates, the Model decides, and the View presents.

When reviewing a change, it helps to ask whether a responsibility sits in a component that changes for a different reason.

keep the HTTP request and response at the input and presentation boundaries
name application operations after user intent rather than technical CRUD steps when the domain calls for it
do not expose complete ORM objects in public JSON without a deliberate contract
enforce server-side authorisation before returning order details
test business rules outside the template and controller
choose the number of classes according to flow complexity and likely changes

Common questions

MVC without common misconceptions

Is the Model in MVC the same as a Doctrine Entity?

No. A Doctrine Entity may be one object in a data or domain model, but the MVC Model has broader responsibility for application state and rules. It may include services, query models, and other objects.

Does business logic belong in the Controller?

A controller may coordinate input and the response, but material rules should remain in the application or domain layer. Otherwise they cannot be reused sensibly from another entry point or tested independently.

Is a View always an HTML template?

No. For a traditional page it is often a template or presenter. In a JSON API, a responder or serializer may fulfil the presentation responsibility by creating the representation and HTTP response.

Is MVC the same as three-tier or Clean Architecture?

No. MVC organises collaboration around user input and presentation. Layered and Clean Architecture describe the wider organisation of an application and the direction of its dependencies.

How I use MVC in practice

I keep the HTTP layer focused on coordination and the rules within a clear application boundary.

In PHP applications, I shape controllers, services, and the model around the complexity of the particular flow. The goal is safe change, not mechanically filling three directories.

Explore my approach to application architecture Discuss your project