Быстрый обзор
Если вы открыли эту статью, то, вероятно, уже примерно понимаете, что такое django. Тем не менее, на всякий случай стоит упомянуть, что это - высокоуровневый веб-фреймворк для Python. Причем высокоуровневый, как мне кажется, не очень подходящее слово, так как оно не в полной мере описывает то, насколько много в django неинтуитивных моментов, которые узнаются исключительно при прочтении документации.
В этой статье я кратко опишу основные компоненты структуры django-приложения и механики его работы для тех, кому нужно быстро понять основные принципы для дальнейшего исследования.
Структура имеет значение
Типичная структура любого django-проекта:
my_root_app_name/
manage.py
my_root_app_name/
__init__.py
settings.py
urls.py
wsgi.py
my_second_app_name/
__init__.py
apps.py
models.py
migrations/
urls.py
views.py
Сразу возникает вопрос: откуда берутся такие названия файлов, и на что они влияют? На самом деле каждое название файла или директории в этой структуре имеет смысл и используется для задания расположения общих для всех django-приложений элементов логики:
__init.py__ пустой файл, необходимый для определения директории как Python-модуля
manage.py главный скрипт для настройки проекта
settings.py настройки приложения, по сути его env-перменные
urls.py структура маппингов url-паттернов на контроллеры
wsgi.py утилита с кодом конфигурации запуска wsgi-сервера
apps.py задание конфигурации приложения
models.py код классов моделей
migrations/ директория с кодом файлов миграций БД
views.py код контроллеров
Manage скрипты
Ключевым элементом структуры по сути является описанный выше manage.py. Через него можно выполнять различные скрипты для управления приложением, например:
- makemigrations - сгенерировать миграции по изменениям из файлов models.py
- migrate - применить миграции к подключенной БД
- runserver - запустить приложение с настройками из wsgi.py
- shell - запустить python в окружении проекта
Кроме этих и других встроенных команд можно написать свои скрипты для запуска из manage.py .
Модели и миграции
Как уже было сказано, миграции генерируются и применяются в manage.py . Файлы models.py содержат описание моделей и их полей в определенном формате, а также другой код, например:
class MyModel(models.Model):
my_user = models.ForeignKey(User, db_index=True, on_delete=models.CASCADE)
my_int = models.IntegerField(default=0)
def some_method():
do_something()
Объекты классов моделей обладают встроенными методами, позволяющими вызывать запросы БД:
# Выборка с фильтром и удаление объекта
objects = MyModel.objects.filter(my_user.id=id).delete()
# Запись в бд
my_instance = MyModel()
my_instance.save()
Обработка запроса
Вернемся к файлам urls.py. В них, как уже говорилось, содержатся маппинги url'ов на классы либо методы обработчиков (views):
from . import views
urlpatterns = [
path('auth/login', views.login),
path('index', views.IndexView),
]
Сами обработчики выглядят так:
from django.views import View
# class view
class IndexView(View):
def get(self, request, *args, **kwargs):
return HttpResponse('Hello, World!')
from django.views.decorators.http import require_http_methods
# method view
@require_http_methods(['GET', 'POST'])
def login(request
Стоит обратить внимание на то, что в class view название метода должно соответствовать типу принимаемого запроса (get, post, put и.т.д.) и на то, что тело запроса будет десериализовано в объект request, который будет передан в аргументы метода обработчика.
Настройки
Файлы settings.py выполняют роль хранилищ переменных среды. Например, задав в settings.py переменную EXAMPLE_VAR:
EXAMPLE_VAR = 'SOME_VALUE'
Ее можно будет получить в любых файлах приложения посредством следующих действий:
from django.conf import settings
print(settings.EXAMPLE_VAR)
Заключение
В целом, приведенной выше информации должно хватить для понимания архитектуры и принципов функционирования приложений, написанных на Django, и понять, готовы ли вы к магическим названиям методов и файлов, при переименовании которых приложение перестанет запускаться :)