MVC architecture

Teams use MVC because it answers the first question every application faces: where does this code go? Keeping data and rules apart from the screens that show them means a change to one rarely forces a change to the other, and each part can be tested without the rest.

What are the parts of MVC architecture?

• Model. The application’s data and the rules that govern it. An Order model knows what an order contains, which status changes are allowed and how to load and save itself. It knows nothing about screens.
• View. What the user sees: an HTML template, a native screen or a JSON response. A view reads from the model and renders it, and holds no business rules of its own.
• Controller. The part that receives input, such as an HTTP request or a button press, decides which model operation it means and chooses the view that should respond.

The three parts are joined by a few fixed relationships. The controller depends on the model and the view. The view depends on the model. The model depends on neither, which is what makes it reusable across a web view, a mobile view and an API.

How does an MVC request work?

Follow the numbers in the diagram at the top of this page. The browser sends GET /orders/42, and the framework’s router hands the request to the orders controller (1). The controller asks the Order model for order 42 (2). The model runs the query against the database, applies any rules such as hiding cancelled orders from customers and returns the data. The controller passes that data to the order view (3), which fills a template and returns the HTML response to the browser (4).

In the original desktop form of the pattern, the model notifies the view directly whenever it changes, and the view redraws. Web frameworks cannot push to a browser mid-request, so the controller carries the data from model to view instead. Both are called MVC, which is why diagrams of the pattern disagree about the arrows.

What are the variants of MVC?

Pattern	Middle component	How the view updates	Typical use
MVC	Controller	The model notifies the view, or the controller passes data to it	Server-rendered web frameworks
MVP	Presenter	The presenter calls methods on a passive view interface	Desktop and older mobile applications that need testable views
MVVM	View model	Data binding keeps the view and the view model in sync	WPF, Android, Vue and other binding frameworks

MVP makes the view as thin as possible so that all logic sits in a presenter that can be unit tested without a user interface. MVVM goes one step further by removing the explicit update calls: the view binds to properties on the view model, and the framework redraws when they change. The model is the same in all three.

How do you apply MVC?

1. Start with the model. Name the entities and the rules that apply to them before writing a screen. A class diagram of the model is a good first artifact.
2. Map input to controllers. Group related actions, such as listing, showing and updating orders, into one controller.
3. Write views that only render. If a template needs a loop and a conditional, fine. If it needs a calculation, move the calculation into the model or a helper.
4. Keep controllers thin. A controller should read the request, call one or two model methods and pick a view. Anything longer belongs in the model.
5. Draw the request cycle. An architecture diagram of one request through the three parts is the fastest way to show a new engineer where code goes.

What are common MVC mistakes?

• Fat controllers. Business rules accumulate in controllers because that is where the request arrives. Over time the model becomes a bag of fields and the controllers become untestable.
• Logic in views. A template that computes a discount has copied a rule that already exists, or should exist, in the model.
• Models that know about HTTP. A model that reads request parameters or sets cookies can no longer be reused by a job or an API.
• Confusing MVC with tiers. MVC organizes code inside one application. It says nothing about which hosts the parts run on, which is the job of three-tier architecture.

How does MVC compare with other architectures?

Pattern	What it organizes	Relationship to MVC
Three-tier architecture	Where the parts of a system run	MVC usually lives inside the application tier
Monolithic architecture	How many deployables a system has	Most MVC frameworks produce one monolith
Client-server architecture	Who makes requests and who answers them	The server side of a web application is often MVC
Layered architecture	Which code may call which	MVC is a layered pattern with three named layers
Microservices	How a system is split into services	Each web-facing service can be MVC inside, behind an API gateway

In a system architecture diagram, an MVC application is a single box, and system design decides how that box is deployed and scaled. The pattern only becomes visible when you zoom in to the components inside it, which is level 3 of the C4 model.

What tools can you use to document an MVC architecture?

• Framework generators. Rails, Django and similar frameworks create the folders and base classes for you, which enforces the pattern better than any diagram.
• UML tools. A class diagram for the model and a sequence diagram for one request are the two standard views of an MVC application.
• AI diagramming tools. Tools like Eraser turn a description of your models, controllers and views into a component diagram or a sequence diagram you can keep editing as the application grows.

For more on this kind of diagram, see design docs.

Frequently asked questions