Django — это высокоуровневый веб-фреймворк на Python для разработки сайтов и веб-приложений с базой данных. Он берет на себя типовые задачи веб-разработки — маршрутизацию запросов, работу с базой данных через ORM, генерацию HTML, аутентификацию и защиту от распространенных уязвимостей — готовыми компонентами вместо кода с нуля. Ниже — как устроена архитектура Django, чем она отличается от классического MVC, из чего состоит проект и минимальный рабочий пример.
Содержание
Откуда взялся Django
Фреймворк разрабатывался в 2003-2005 годах в редакции американской газеты Lawrence Journal-World для быстрого выпуска новостных сайтов с большой нагрузкой на публикацию контента. Авторы — Адриан Головатый (Adrian Holovaty) и Саймон Уиллисон (Simon Willison). В июле 2005 года код выложили в открытый доступ под BSD-лицензией. Название — в честь джазового гитариста Джанго Рейнхардта. Сейчас проект развивает некоммерческий Django Software Foundation.
Django выпускает релизы примерно раз в 8 месяцев, каждый третий релиз получает статус LTS (long-term support) с продленной поддержкой безопасности — около 3 лет вместо примерно 16 месяцев у обычного релиза. На сентябрь 2026 действующая LTS-версия — Django 5.2 (вышла в апреле 2025 года, поддержка до апреля 2028) — для новых проектов рекомендуется именно она.
Архитектура MTV, а не MVC
Django часто по инерции называют MVC-фреймворком, но сам проект описывает свою архитектуру термином MTV (Model-Template-View), и путать эти два обозначения не стоит — роли компонентов совпадают лишь частично:
| Классический MVC | Компонент Django | Что делает в Django |
|---|---|---|
| Model | Model | Описывает структуру данных и работает с базой через ORM |
| View | Template | Отвечает только за отображение — HTML-разметку и подстановку данных |
| Controller | View | Принимает запрос, обращается к моделям, выбирает шаблон и формирует ответ |
Ключевая разница термина: то, что в MVC называется View (слой отображения), в Django называется Template. А то, что в MVC называется Controller (логика обработки запроса), в Django называется View. Из-за этого при чтении документации Django слово «view» нужно понимать как «обработчик запроса», а не как «визуальный шаблон» в терминах MVC. Django сам определяет свой подход как MTV, при этом Controller в нем частично встроен в сам фреймворк — в виде маршрутизатора URL, который выбирает нужный view.
Из чего состоит проект
Проект Django — это набор приложений (apps), каждое из которых отвечает за свою предметную область (блог, каталог, аутентификация). Стандартные элементы:
- URL-маршруты (
urls.py) — сопоставляют адрес запроса с обработчиком. - View — функция или класс, которая получает запрос, обращается к моделям и возвращает ответ.
- Model — описание таблицы базы данных на Python через ORM (Object-Relational Mapping).
- Template — HTML-файл с мини-языком шаблонов Django для подстановки данных.
- Миграции — файлы, которые описывают изменения схемы базы данных и накатывают их без ручного SQL.
Кроме этого в комплект входят: встроенная админ-панель, аутентификация и авторизация, middleware для кеширования, интернационализация, тестовый веб-сервер для разработки и защита от CSRF и других типовых веб-атак. Такой набор «из коробки» — причина, почему Django называют фреймворком с батарейками (batteries included).
ORM и миграции на примере
Модель описывает таблицу как обычный класс Python:
# blog/models.py
from django.db import models
class Post(models.Model):
title = models.CharField(max_length=200)
body = models.TextField()
created_at = models.DateTimeField(auto_now_add=True)
def __str__(self):
return self.titleПосле описания модели нужно создать и применить миграцию:
python manage.py makemigrations blog
python manage.py migrateЧастая ошибка новичка — забыть добавить приложение в INSTALLED_APPS в settings.py. В этом случае makemigrations не найдет модель вовсе:
No changes detected
Исправление — добавить 'blog' в список INSTALLED_APPS и повторить makemigrations. После этого команда создаст файл миграции, а migrate применит его к базе данных (по умолчанию для нового проекта это SQLite).
Минимальный рабочий пример
Обработчик запроса и маршрут для вывода списка постов:
# blog/views.py
from django.http import HttpResponse
from .models import Post
def post_list(request):
posts = Post.objects.order_by('-created_at')
titles = [p.title for p in posts]
return HttpResponse('<br>'.join(titles) or 'Постов пока нет')# blog/urls.py
from django.urls import path
from . import views
urlpatterns = [
path('posts/', views.post_list, name='post_list'),
]После запуска python manage.py runserver и перехода на /posts/ на пустой базе браузер покажет строку «Постов пока нет» — в базе еще нет ни одной записи модели Post.
Встроенная админка
Регистрация модели в админ-панели занимает одну строку:
# blog/admin.py
from django.contrib import admin
from .models import Post
admin.site.register(Post)Учетную запись администратора создает отдельная команда, запускать которую стоит только в контролируемом окружении разработки (в проде — через защищенный канал доступа, а не публично):
python manage.py createsuperuserКоманда интерактивно запросит логин, e-mail и пароль. После входа на /admin/ появляется готовый интерфейс для создания, просмотра, редактирования и удаления записей Post — без единой строки собственного HTML или JavaScript.
Преимущества и ограничения
| Плюс | Пояснение |
|---|---|
| Полнота из коробки | ORM, админка, аутентификация, миграции — без сторонних пакетов для базового CRUD |
| Готовая защита | Встроенная защита от CSRF, SQL-инъекций через ORM, XSS-экранирование в шаблонах по умолчанию |
| Масштабируемость по приложениям | Проект делится на независимые apps, каждое можно развивать и тестировать отдельно |
| Зрелая экосистема | Долгая история, документация, множество готовых пакетов (DRF, django-allauth и другие) |
| Ограничение | Пояснение |
|---|---|
| Монолитность | Многие решения (ORM, шаблонизатор) встроены и завязаны друг на друга — заменить только ORM на другой не так просто, как в микрофреймворках |
| Порог входа в маршрутизацию | URL-паттерны используют регулярные выражения или конвертеры путей — синтаксис нужно выучить отдельно |
| ORM не для всех задач | ORM Django упрощает типовые запросы, но для сложной аналитики или нестандартных SQL-конструкций иногда нужен raw() или прямой SQL |
| Асинхронность частичная | Базовая поддержка async view (async def вместо def) появилась в версии 3.1, асинхронные методы ORM (aget, acreate и другие) — в версии 4.1; зрелость по разным частям стека отличается — актуальное состояние стоит проверять в release notes используемой версии |
Утверждение «Django не умеет обрабатывать несколько запросов одновременно» из старых источников устарело: под управлением WSGI/ASGI-сервера с несколькими воркерами Django параллельно обслуживает много запросов, а с версии 3.1 поддерживаются async view для операций, упирающихся в ожидание (сеть, внешние API), с версии 4.1 к ним добавились асинхронные методы ORM.
Когда выбирать Django
Django имеет смысл, когда проекту нужны база данных, аутентификация пользователей и админка для контента — типичные примеры: внутренние CRM, каталоги, блоги, SaaS-сервисы среднего размера. Для чистого REST/GraphQL API поверх Django обычно добавляют библиотеку Django REST Framework — сам по себе Django ориентирован на full-stack приложения с шаблонами, а не только на выдачу JSON.
Для очень маленького сервиса из одного эндпоинта (например, вебхука) монолитность Django может быть избыточной — чаще берут микрофреймворк вроде Flask или FastAPI. Выбор зависит от масштаба задачи, а не от того, что Django устарел — для проектов с базой данных и админкой это по-прежнему используемый вариант на Python.
Выводы
- Django — высокоуровневый Python-фреймворк с готовыми ORM, миграциями, админкой и защитой от типовых атак.
- Архитектура называется MTV (Model-Template-View), а не MVC: Template в Django — это слой отображения из MVC, а View — это уровень логики обработки запроса (аналог Controller).
- Минимальный проект — модель, миграция, view, маршрут — разворачивается за несколько команд без ручного SQL и HTML для админки.
- Часть ограничений из старых статей (отсутствие многозадачности, «устаревший ORM») не соответствует текущим версиям — асинхронные view есть с 3.1, асинхронные методы ORM — с 4.1, ORM активно развивается.
- Django эффективен для проектов с базой данных и админкой; для одного простого эндпоинта монолитность фреймворка может быть избыточной.
Где применяется / связь с практикой
Освойте тему на практике
Архитектуру MTV, ORM и админку из этой статьи разбирают на практике на курсе Django — от первого проекта до деплоя. Если пока не уверены, что Django — ваш инструмент, можно начать с бесплатных открытых уроков Otus и посмотреть на живой разбор кода перед записью на полный курс.
FAQ
Django — это библиотека или фреймворк?
Фреймворк: в отличие от библиотеки, которую вызывает ваш код, Django сам управляет структурой проекта и вызывает ваш код (модели, view) по своим правилам — это называется инверсией управления.
Можно ли на Django делать только API, без HTML-шаблонов?
Да, но для этого обычно подключают отдельную библиотеку Django REST Framework поверх Django — сам фреймворк из коробки ориентирован на full-stack приложения с шаблонами, а не только на выдачу JSON.
Нужно ли учить SQL, если Django дает ORM?
Да: ORM закрывает большинство типовых запросов, но понимание SQL нужно для оптимизации медленных запросов, чтения EXPLAIN и написания сложных выборок через raw(), которые ORM неудобно выразить.
