What Django actually is — MVT and the request/response basics

Before models, views, or ORMs make sense individually, it helps to see the one thing they're all part of — turning an incoming web request into an outgoing response.

Beginner

3 min read

The one thing every web framework actually does

A web server's whole job, stripped down, is: receive a request (a browser asking for a URL), figure out what that request wants, and send back a response (usually HTML, or JSON for an API). Django is a framework for building that — it provides the plumbing (routing requests to your code, talking to a database, rendering HTML) so you write the parts specific to your actual application, not a URL parser or a database connection handler from scratch every time.

MTV: Django's name for a common pattern

Django organizes an application into three kinds of pieces, and calls the pattern MTV (Model-Template-View — a deliberate variant naming of the more widely-known MVC, Model-View-Controller, pattern):

Model — defines what data looks like and talks to the database (covered in its own lesson: models and migrations).
Template — an HTML file with placeholders, that gets filled in with real data before being sent to the browser.
View — a Python function (or class) that receives a request, decides what data it needs, and returns a response — usually by filling in a template with that data.

The naming is genuinely confusing coming from other frameworks: what Django calls a "View" is closer to what other frameworks call a "Controller" (it makes decisions and orchestrates), and Django's "Template" is what other frameworks call a "View" (the actual presentation/HTML layer). If Django's terminology ever seems backwards compared to something you've read elsewhere, this naming swap is usually why.

Following one request all the way through

Every one of Django's individual lessons — URLs and views, models and migrations, middleware, the ORM's lazy querysets — is really just zooming into one step of this same flow. Keeping this whole picture in mind is what makes the individual pieces click into place, rather than feeling like unrelated trivia.

`manage.py`: the command-line tool you'll run constantly

python manage.py runserver      # start a local development server
python manage.py migrate         # apply database schema changes
python manage.py makemigrations  # generate new schema-change files from model changes
python manage.py createsuperuser # create an admin account

Every Django project gets a manage.py file at its root, generated automatically. It's the entry point for nearly everything you'll do outside of writing actual application code — starting the dev server, managing the database schema, and a long list of other built-in and custom commands (python manage.py help lists them all).

A project vs. an app — a real, load-bearing distinction

A Django project is the whole website — its settings, its top-level URL configuration, and one or more apps inside it. An app is a self-contained module handling one piece of functionality — a blog, a user-accounts system, a payments system — each with its own models, views, and URLs, designed to be reusable and, ideally, droppable into a different project with minimal changes. A small site might have just one app; a larger one splits functionality across several. This isn't just organizational preference — Django's own tooling (migrations, the admin, app-specific settings) is built around the assumption that code lives inside an app, not loose in the project.