Ruby on Rails, Laravel, and ASP.NET Core are all organized around MVC. The name stands for Model-View-Controller, and the idea is to split an application so that the model holds data and business rules, the view handles presentation, and the controller deals with user input.
In practice that means a team can redesign a screen without touching business rules.
According to its Zenodo archive record, Trygve Reenskaug’s Xerox PARC note of 10 December 1979 was the first to define the terms model, view, and controller. It came nearly seven months after his May 1979 note titled Thing-Model-View-Editor.
The pattern is older than the web by more than a decade, which is why the controller means different things on the desktop and in a web framework.
What is MVC?
Splitting an application into a model, a view, and a controller is the whole idea. The model covers data and rules, the view covers presentation, and user input goes through the controller.
Each part has one job and a defined way of talking to the other two. Redesign a screen and the business rules stay untouched. Change a rule and the screen stays as it was.
The pattern organizes the user interface layer of an application. It has nothing to say about the database or the network, and deployment is outside its scope entirely.
The model carries application data, state, and business rules. The view is whatever the user looks at. The controller takes input, updates the model, and picks the view.
Is MVC a design pattern or an architecture?
Both labels are in use, sometimes inside the same documentation set. Microsoft’s ASP.NET Core documentation uses both terms for MVC. Apple’s Cocoa documentation says design pattern, while the Rails Guides go with architecture.
The difference is scope. An architectural pattern fixes how a whole layer is organized, so MVC sits at the level of software architecture.
Most software design patterns solve narrower problems, such as one object notifying others of a change. This article calls MVC an architectural pattern because it arranges the parts of an application rather than the exchange between two classes.
What do the model, view, and controller each do?
Data and business rules belong to the model. Rendering is the view’s job. The controller sits between them, turning user input into model changes and choosing which view to show.
Model
The model holds application state and the rules that change it. In a web shop it calculates an order total and applies a discount before saving the result.
It contains no HTML and no formatting, and it never refers to a view or a controller. Any interface that needs the same data can use it.
Microsoft Learn is clear about the dependency direction. The view and the controller depend on the model, and the model depends on neither. That one-way rule lets a model be built and tested without any screen attached.
View
A view presents what the controller hands it and does very little else.
The Rails Guides describe the view as the part that renders responses in formats such as HTML, JSON, and XML. The same model data can feed a web page and a mobile screen, and even a PDF report, each through its own view.
Microsoft’s guidance is to keep any logic in a view limited to presentation. A discount rule written inside a template gets copied or broken the next time the page is redesigned.
Controller
A controller receives a request or user action along with its parameters. It calls the model to read or change data, then chooses a view and passes along whatever data that view needs.
Its job is coordination. Calculating and formatting aren’t part of it, and Microsoft Learn advises pushing business logic out of controllers and into the domain model.
How does an MVC request flow work?
The router maps an incoming URL to a controller action. That action reads or changes data through the model, then selects a view to render the response.
Here is what happens when a visitor opens a product page in a web shop.
- The browser sends a GET request for /products/42.
- The router matches the URL to the show action of the products controller.
- The controller asks the model for product 42.
- The model reads the record and returns it with its price rules applied.
- The controller picks the product view and passes it the data.
- The view renders HTML.
- The framework sends the response back to the browser.
Many frameworks put a single entry point in front of every controller. Spring MVC is built around the front controller pattern, with its DispatcherServlet running the shared request-processing steps (Spring Framework reference).
ASP.NET Core gets to the same place through routing first. Its routing engine parses the URL and matches it against the defined formats before calling the associated action method.
Model notifications on desktop and on the web
On the desktop, something has to refresh the screen when model data changes. Apple’s archived Cocoa documentation has the changed model notify a controller, which then updates the views. In many desktop implementations the model notifies its views directly through the Observer pattern, so it never needs to know which views exist.
A standard request-response web app works differently. The server answers requests instead of pushing changes to the browser, so the notification step mostly disappears and each request produces a fresh render.
Where validation and error handling sit
Validation lives on the model. ASP.NET Core MVC validates model objects through data annotation attributes.
Authorization and exception handling go in filters wrapped around controller actions, which Microsoft describes as the place for cross-cutting concerns. Showing the errors is left to the view, which uses the messages the model produced.
Where did MVC come from?
Trygve Reenskaug formulated MVC in 1978/79 as a visiting scientist at Xerox PARC, while working with the Smalltalk group.
His stated goal was a general solution to the problem of users controlling a large and complex data set (University of Oslo repository of the original reports).
A few dates anchor the history.
- Reenskaug spends 1978/79 at Xerox PARC as a visiting scientist.
- On 12 May 1979 he writes the first report, “Thing-Model-View-Editor”, which names four parts including an Editor.
- The note of 10 December 1979, “Models-Views-Controllers”, is the first to define model, view, and controller.
- In August/September 1988, Krasner and Pope describe MVC in Smalltalk-80 (Journal of Object-Oriented Programming, volume 1, issue 3, pages 26 to 49).
Reenskaug’s first set of names was Model-View-Editor. After long discussions with Adele Goldberg, the name settled as Model-View-Controller.
How web MVC differs from the original
In Smalltalk-80 in 1988, each view is paired with a controller that handles keyboard and mouse input. Each controller has exactly one model, while one model can have many view and controller pairs (Krasner and Pope).
Web frameworks use a single controller instead. It handles an incoming HTTP request, works with the model, and selects the view. Microsoft’s ASP.NET Core documentation calls the controller the initial entry point for a request.
Same name, different job. That is why two developers can both say “MVC” and describe different designs.
Benefits of MVC for a codebase
The main thing MVC buys you is cheaper change. Testing and dividing the work get easier too, because each part has one job and one direction of dependency.
Cheaper interface changes
Interfaces get redesigned far more often than business rules.
Microsoft Learn makes the same point, saying user interface logic tends to change more often than business logic. When both sit in one object, every interface tweak forces the business rules to be retested. With the parts separated, a redesign touches views only.
Parallel work and testing
A team can split along the three parts. Front-end work happens in views and templates while other developers build models and controllers against an agreed interface.
A model has no screen attached, so unit tests run against it directly. Microsoft documents controller logic as testable without a browser as well.
Reuse across clients
ASP.NET Core MVC supports Web APIs that serve browsers and mobile devices alike, so one model can sit behind a web page and a mobile screen, and a report can draw on it too. Apple’s Cocoa documentation adds that model objects carry over to similar problem domains.
What the platform documentation claims
The Microsoft, Rails, and Apple documentation all list the same kind of benefit, which is easier change and reuse. The 3.1 edition of the Rails Guides names isolation of business logic from the interface and clearer code placement, and Apple’s Cocoa documentation points to reusable, extensible objects.
In the passages cited here, none of the three claims that MVC makes an application run faster. Choose it for team structure and testability, not for speed.
The pattern does not enforce its own boundaries, so the gains last only as long as the team keeps them.
How to organize an MVC project
Put code in model, view, and controller folders, and keep business rules in the model. Controllers stay thin.
Folder layout
Rails keeps controllers, models, views, helpers, mailers, jobs, and assets inside one app directory (Rails Guides, Rails 8.1). ASP.NET Core MVC uses separate folders for models, controllers, and views, and ties them together through naming conventions.
Large applications outgrow one set of folders. ASP.NET Core MVC offers areas for that, and each area is effectively an MVC structure of its own inside the app.
Where each kind of code goes
Rules and calculations go in the model. The 3.1 edition of the Rails Guides puts the bulk of an application’s business logic there.
Shared services get handed to the controller instead of being created inside it. When a view needs heavy logic, a view model or view component takes over the display preparation, and the controller only does a thin pass of input checks.
Services reach a controller through its constructor. ASP.NET Core MVC supports this natively through dependency injection, which keeps each controller’s dependencies visible.
What goes wrong
Most MVC projects fail the same way. Logic drifts toward the controller.
Fat controllers have long actions that repeat the same steps and hold rules that belong in the model. Microsoft Learn suggests moving repeated actions into filters.
Views have the opposite problem when templates start branching on business conditions. Microsoft points to view components, view models, or view templates once a view needs that much logic.
Apple’s View Controller Programming Guide lets a view controller validate input and package it for the data objects. It also says to keep the controller’s role in managing the data itself small.
Rails, Apple, and Android reach the same rule from different directions. Android’s architecture recommendations state that the data layer holds the vast majority of an app’s business logic.
A controller that has already bloated is a straightforward code refactoring job. Extract the rule into the model or a service, and leave the action with a few lines.
MVC frameworks by language
Every major web stack has at least one. ASP.NET Core MVC covers C#, Spring MVC covers Java, Rails is Ruby’s, Laravel is PHP’s, and Django handles Python while renaming the parts.
| Framework | Language | How it maps to MVC |
|---|---|---|
| ASP.NET Core MVC | C# | Controller actions, Razor views, model binding |
| Spring MVC | Java | Annotated @Controller classes, view resolution |
| Ruby on Rails | Ruby | Active Record models, Action View, Action Controller |
| Laravel | PHP | Controllers in app/Http/Controllers, Blade views |
| Django | Python | MTV: model, template, view; the framework acts as controller |
Spring Web MVC is the original web framework in the Spring Framework, included from the very beginning according to the Spring documentation.
ASP.NET Core adds model binding, which converts form values, route data, query strings, and headers into objects the controller can handle (Microsoft Learn).
Django renames the parts
Django’s FAQ calls the standard MVC names debatable. A Django view decides which data is presented, a template decides how it looks, and the framework itself plays the controller, sending each request to the right view according to the URL configuration.
The vocabulary trips people up. A Django view is not an MVC view, while a Rails view is a template.
Express.js has no fixed layout
The Express documentation (version 5.3.0) describes it as a fast, unopinionated, minimalist framework built on routing and middleware.
Some tutorials still list Express among MVC frameworks. The two positions differ because Express imposes no model or view structure, so any MVC layout in an Express project is a convention the team brings.
Apple UIKit pairs view and controller
In iOS development, the controller role belongs to UIViewController, which Apple documents as the object that manages a view hierarchy.
It is tightly bound to the views it manages and takes part in handling events in that view hierarchy. It also acts as an intermediary between views and the app’s data.
MVC vs MVP and MVVM
MVC keeps a controller that handles input and selects the view. MVP swaps it for a presenter that updates the view directly. MVVM goes with a view model instead, and the view binds to it.
| Pattern | Middle part | How the view stays current | View depends on model |
|---|---|---|---|
| MVC | Controller | Controller selects the view and hands it model data | Yes |
| MVP (Passive View) | Presenter | Presenter updates the view directly | No |
| MVVM | View model | Data binding syncs view and view model | No |
The last column is the real divider. Microsoft’s ASP.NET Core documentation has the view depend on the model, while its .NET MAUI documentation has the view model isolate the view from the model.
MVP: presenter and passive view
In the Supervising Controller variant, the view handles simple mapping to the model while the controller handles input response and complex view logic (Martin Fowler’s definition).
Passive View goes further. The view no longer updates itself from the model, and the presenter does it instead, according to Fowler’s Passive View page.
That split replaced plain MVP as a label. Fowler retired the original pattern name in favor of the two variants.
MVVM: view model and data binding
Fowler published Presentation Model on 19 July 2004 and lists MVVM as another name for it. Microsoft later built its XAML tooling around the idea.
In the MVVM pattern, the view and view model connect through data bindings, and view model properties raise a PropertyChanged event so two-way binding works (.NET MAUI documentation).
The model knows nothing about the view model, and the view model knows nothing about the view. What the view mainly depends on is the binding to its view model.
Which one to pick
For server-rendered pages, MVC fits, since each request produces one response and no live synchronization is needed.
Toolkits with native data binding point toward MVVM. Microsoft calls it a natural choice for .NET MAUI apps that bind properties to the underlying data.
On Android, the official architecture recommendations center on a ViewModel that exposes UI state to the UI layer.
For a longer side-by-side, see this MVC vs MVVM vs MVP comparison.
When MVC does not fit
MVC adds three layers and a set of conventions. It rarely pays off for single-purpose APIs, and throwaway tools or screens driven by live data binding don’t benefit much either.
Small APIs and single-purpose tools
As of October 2026, Microsoft Learn recommends Minimal APIs for new ASP.NET Core HTTP API projects. Controller-based APIs remain the alternative for needs such as model binding extensibility.
An endpoint that returns JSON for a RESTful API has no view to render, so one of the three parts is empty from the first commit.
Express’s own starter app answers a request in a handful of lines.
Where official guidance disagrees
The Rails Guides generate controllers, models, and views from the first command. Microsoft’s API guidance steers new projects away from controllers by default.
Both are authoritative, and the difference is the output. Rails builds pages that need views, while API endpoints return data. MVC is the default for page-rendering apps, not for data endpoints.
A decision rule
I’d skip MVC in a few cases.
- A single-purpose API with no views
- A prototype or internal one-page tool with one maintainer
- A screen driven mostly by two-way data binding
Keep it for server-rendered sites with several contributors, apps where one model feeds several views, and codebases expected to outlive their first team.
Choose the structure after you know how many views, developers, and years the app will have.
MVC FAQ
Does MVC run on the front end or the back end?
It depends on the platform. In server-rendered web frameworks such as Rails and ASP.NET Core, all three parts run on the server and the view returns HTML.
In iOS and desktop apps, they all run on the user’s device.
How does MVC differ from three-tier architecture?
Three-tier architecture divides a whole system into presentation, business logic, and data tiers, usually deployed separately. MVC divides the code of the user interface layer into model, view, and controller.
The two coexist. An MVC web app can serve as the presentation tier.
Are React and Angular MVC frameworks?
The label is contested. Some tutorials list Angular and React among MVC frameworks, yet both build screens from components that bundle a template with logic, not from separate controllers.
Treat the tag as loose shorthand.
Is ASP.NET Core MVC the same thing as MVC?
No. MVC is the general pattern, while ASP.NET Core MVC is Microsoft’s framework that applies it to C# web apps.
Spring MVC, Rails, and Laravel are other implementations of the same idea.
Does MVC stand for anything outside software?
Yes. The same letters abbreviate the New Jersey Motor Vehicle Commission and the Missouri Valley Conference, among others.
In programming, the term always means Model-View-Controller.
Choosing a Framework to Learn MVC First
Learn MVC in the framework for the language you already use, such as ASP.NET Core MVC, Spring MVC, Rails, or Laravel. The three-part split transfers between stacks, while syntax does not.
Build one resource end to end first. Then add a second view of the same model, and write a model test that runs without a browser.
Convention-heavy frameworks such as Rails teach the layout fastest, at the cost of hiding how routing connects the parts.
Django and Express suit a second project better, since Django renames the parts and Express supplies no structure.
Once the first app runs, layered architecture covers the database and service layers that the pattern leaves out.
- What Communications Teams Should Ask Before Commissioning a Mobile App - November 12, 2026
- How to Install Node JS in VS Code and Run Your First Script - November 11, 2026
- Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026
