CodeOath
← All posts
Python65 min total · 18 parts

Django Fundamentals: The ORM, Migrations, and Shipping a Real App

Part 2 of 18 · ~1 min

MVT, and Why the Names Don't Mean What They Sound Like

If you've touched an MVC framework before, Django's own vocabulary is going to actively mislead you for about five minutes, and it's worth getting that confusion out of the way before ToolShed has a single line of code.

In DjangoWhat it actually doesWhat you'd call it in MVC
ModelDefines a tool or a loan as data, and talks to the database on its behalfModel — same word, same job
ViewDecides which tools to fetch for this request and which template renders themController — despite the name
TemplateThe HTML that turns fetched tools into a page a neighbor can readView — the thing MVC actually calls a "view"

The word "View" is doing two different jobs depending on which framework's mouth it's coming out of. In Django, a view is a Python function or class that makes decisions — which tools to show, whether the visitor's allowed to see them — and hands the result to a template. In classic MVC, the "view" is the rendering layer itself, which is what Django calls a template. Nothing about the underlying architecture is unusual here; it's the same three-layer split you've likely already internalized, wearing one swapped label. Django also inserts a fourth piece MVC diagrams tend to fold silently into "the controller" — a routing layer (urls.py) that decides which view even gets a turn for a given URL, kept explicit rather than implied.