MTV & the Request Path

## The short answer Django does not use a different architecture from **MVC** (model-view-controller); it uses different **names**. Django's documentation calls the split **MTV** — model, template, view — and its FAQ explains why: in Django's reading, a *view* describes **which data** is presented, not **how it looks**. The job MVC gives to a controller is done by the framework's own request machinery. ## How the three letters map | MVC term | Django term | Where the code lives | What it decides | |---|---|---|---| | Model | **Model** | `models.py`, classes subclassing `django.db.models.Model` | the data, its fields, relations and behaviour | | Controller | **View** (plus the framework) | `views.py`, function or class-based views | which data a request gets, and which response is returned | | View | **Template** | `templates/` directories, Django template language | how the chosen data is rendered as HTML or text | The row that confuses people is the middle one. A Django **view** is a Python callable that receives an `HttpRequest` and must return an `HttpResponse`. It reads the request, queries models, and chooses what to send back. That is controller-like work in MVC terms. The **template** is the presentation layer that MVC would call the view. ## Where the controller went Django's FAQ says the controller is "probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration". Concretely, that machinery is: 1. The **handler** — `WSGIHandler` or `ASGIHandler` — which turns the server's call into an `HttpRequest`. 2. The **middleware** chain listed in the `MIDDLEWARE` setting, which wraps every request and response. 3. The **URL resolver**, which matches the request path against the URLconf named by `ROOT_URLCONF` and picks the view. You configure this controller (you write `urls.py` and choose middleware), but you do not write it as a class. That is the practical reason Django gives the name *view* to the code you do write. ## Why the naming matters in practice The mapping tells you where code belongs on a real project, such as a recipe-sharing site: - **Query logic** — "the ten newest recipes with their authors" — belongs in the model layer (a model method or a custom manager) or in the view, not in the template. - **Request logic** — reading `request.GET`, checking permissions, choosing a status code or a redirect — belongs in the view. - **Presentation** — loops, formatting, escaping — belongs in the template. The Django template language deliberately limits what a template can compute, which pushes logic back into views and models. - **Routing** — which URL reaches which view — belongs in `urls.py`, which is how you feed the framework's controller machinery. A view does not have to use a template at all. It can return a `JsonResponse`, a redirect or a file; the template is simply the usual way to build an HTML response. That is another reason "view equals template" is the wrong reading of MTV. ## Common confusions - **"A Django view is the HTML page."** No — the HTML comes from a template; the view is the Python code that chooses the data and returns a response. - **"Django has no controller, so routing logic goes in views."** Routing lives in the URLconf; views should not inspect the path to decide what they are. - **"MTV is a different pattern from MVC."** It is the same separation of concerns with Django's own labels, as the FAQ itself says the standard names are "debatable". - **"Templates may query the database freely."** They can trigger lazy queries by touching related objects, but that is an accident to avoid, not the design. ## What an interviewer is listening for A junior candidate should map each letter correctly and say where the controller role went. A stronger answer names the actual pieces — handler, middleware, URL resolver — and uses the mapping to justify where code belongs, for example keeping queries out of templates and routing out of views.