Часть 3: Введение в концепцию моделей. Вот откуда большая часть ценности Django.

Самые продвинутые планы развития науки о данных, которые вы когда-либо видели! Поставляется с тысячами бесплатных учебных ресурсов и интеграцией ChatGPT! https://aigents.co/learn/roadmaps/intro

Добро пожаловать в третью часть серии руководств по веб-разработке с использованием Python и Django. В этой части будет рассмотрена модель, ее объявление и некоторые основные типы полей. Также кратко показаны несколько основных способов доступа к данным модели.

Веб-приложения Django получают доступ к данным и обрабатывают их через объекты Python, называемые моделями. Модели определяют структуру хранимых данных, включая типы полей и их значения по умолчанию, максимальный размер, параметры списка выбора, текст справки для документации, текст метки для форм и т. д. Определение модели не зависит от основной базы данных — вы можете выбрать один из нескольких в рамках настроек проекта. Как только вы решите, какую базу данных использовать, вам вообще не нужно разговаривать с ней напрямую — вы пишете структуру и другой код своей модели, а Django делает за вас всю грязную работу по общению с базой данных.

Проектирование «основных» моделей приложений:

Прежде чем вы начнете кодировать свои модели, стоит потратить несколько минут на то, чтобы подумать о том, какие данные нам нужно хранить и какие отношения между различными объектами мы будем использовать. Для простоты я создам темы о животных (Кошках, Собаках и т.д.) Лучше всего нарисовать, как будут выглядеть ваши столы. Я быстро нарисовал один, но он фундаментальный:

Django позволяет нам позже быстро расширять эти модели, но все же было бы лучше иметь четкое представление о том, как это должно выглядеть.

Имеет смысл иметь отдельные модели для каждого «объекта» (группы связанной информации) при создании моделей. Очевидными объектами являются статья, серия статей и авторы.

Вы также можете использовать модели, чтобы предоставить список вариантов выбора (например, раскрывающийся список вариантов) вместо жесткого кодирования вариантов на самом сайте, что рекомендуется, когда все параметры не известны заранее или могут измениться. .

Принимая решение о наших моделях и области, мы должны думать об отношениях. Как и во многих базах данных, Django позволяет определять отношения «один к одному» (ManyToOneField), «один ко многим» (ForeignKey) и «многие ко многим» ( ManyToManyField).

Создание моделей:

Первая модель, с которой нужно начать, — это модель статей, поскольку статьи (или мы также можем назвать учебные пособия) являются основным аспектом PyLessons.com. Итак, какими могут быть атрибуты статьи? Очевидно, у нас есть заголовок, подзаголовок, слаг, может быть, дата публикации и содержание, как и сама статья. Это важные части, и их должно быть достаточно для начала. Кроме того, мы могли бы придумать больше вещей для статей, например, частью какой серии они являются, в какую категорию они попадают и так далее. При использовании Django добавление дополнительных полей в вашу базу данных требует минимальных усилий, поэтому это не так важно, как вы думаете. Итак, давайте создадим учебную модель. Каждая модель будет уникальным классом в файле model.py вашего приложения.

Давайте начнем с определения модели для вашей статьи здесь:

Все модели будут наследовать от models.Model. Затем мы определяем наши поля. Имейте в виду, что модель может иметь произвольное количество полей, определенных по-разному, любого типа — каждое из которых представляет собой столбец данных, которые мы хотим сохранить в одной из таблиц в нашей базе данных. Каждая запись базы данных (строка) состоит из каждого значения поля. Эти поля соответствуют нашему формату данных в реальной базе данных. Мы ожидаем, что наш заголовок и подзаголовок будут довольно короткими, поэтому мы определяем это как CharField.

Вам может быть интересно узнать разницу между CharField, которое мы используем для имени, и TextField, которое мы используем для самого контента. Обычно мы используем CharField для кого-то с ограниченным размером и текстовым полем, когда у нас нет ограничений. Затем мы хотим иметь URL-адрес нашей статьи, который мы определим с помощью SlugField. Слизняк — это короткая метка, содержащая цифры, буквы, знаки подчеркивания или дефисы. Обычно они используются в URL-адресах.

Вы можете спросить, почему у меня есть slug с @property вместо одного слага в основной модели. Я отвечу на этот вопрос в 6-м уроке, где мы создадим базовый шаблон веб-сайта.

Кроме того, мы хотим знать, когда была создана или изменена наша статья; эту информацию мы сможем записать, имея файл DateTimeField. Подробнее о полях см. в Документации по полям модели Django.

Наконец, мы переопределяем специальный метод __str__, чтобы сделать его немного более читаемым при отображении в виде строки, что мы увидим позже.

Также, как я уже говорил, мы хотим, чтобы у наших статей была какая-то категория или серия. Сейчас я создам его с похожими полями, но мы вернемся к нему в следующем уроке:

Хорошо, каждый раз, когда ваши модели меняются (создается новая модель или модифицируется существующая модель), вы должны выполнять миграцию. Вот два шага. Сначала мы выполняем makemigrations, а затем выполняем саму миграцию. Для этого мы используем скрипт manage.py, поэтому давайте сделаем так: python manage.py makemigrations.

Вы хороши, если не получаете никаких ошибок; в противном случае вам необходимо исследовать их и исправить.

Это действие генерирует код, необходимый для миграции; он еще не применяет изменения. Вы можете просмотреть все свои миграции, посетив каталог миграций приложения, если вам интересно. Теперь давайте применим эти миграции к: python manage.py migrate.

Существует множество различных типов полей, в том числе поля для различных типов чисел (с плавающей запятой, маленьких целых чисел, больших целых чисел), логических значений, URL-адресов, уникальных идентификаторов и другой связанной со временем информации (продолжительность, время и т. д.). Полный список можно посмотреть в Документации Django.

Метаданные:

Ваши метаданные на уровне модели можно объявить, создав внутри новый класс Meta, как в моем примере:

Одной из наиболее ценных функций этих метаданных является управление порядком записей по умолчанию, возвращаемых при запросе модели. Как показано выше, вы делаете это, указывая порядок соответствия в списке имен полей атрибуту упорядочения. Порядок результатов будет зависеть от типа поля (символьные поля сортируются в алфавитном порядке, а поля даты сортируются в хронологическом порядке). Чтобы изменить порядок сортировки результатов, вы можете поставить перед именем поля знак минус (-).

Например, если вы выбрали сортировку по заголовку и дате, введите следующее: ordering = ["title", "-published"]. Элементы будут отсортированы в алфавитном порядке по заголовку от А до Я, а затем по дате публикации в каждом заголовке, от самого нового до самого старого.

Другим распространенным атрибутом в Django является verbose_name, подробное имя класса в единственном и множественном числе: verbose_name_plural = 'Article'.

Другие ценные атрибуты позволяют вам создавать и применять новые «права доступа» к модели (разрешения по умолчанию применяются автоматически), позволяют сортировать по другому полю или объявлять «абстрактный» класс (базовый класс, для которого вы не можете создать записи, а вместо этого будут выведены для создания других моделей).

Многие другие параметры метаданных контролируют, какая база данных должна использоваться для модели и как хранятся данные (они полезны только в том случае, если вам нужно сопоставить модель с существующей базой данных).

Вы можете найти полный список параметров метаданных здесь: Параметры метаданных модели (Django docs).

Методы:

Модель также может иметь методы. Рекомендуется, чтобы каждая модель определяла стандартный метод класса Python __str__() для возврата удобочитаемой строки для каждого объекта. Эта строка представляет отдельные записи на сайте администрирования (и в любом другом месте, где вам нужно сослаться на экземпляр модели). Часто это возвращает заголовок или поле имени из модели.

Эту информацию также можно найти в документации Django.

Создать запись статьи:

Если вы вносили какие-либо изменения в метаданные или методы модели, вам необходимо снова выполнить миграцию, сделать это и двигаться дальше.

Я знаю, это много вещей, чтобы помнить! Но последнее, что нужно сделать, это добавить запись статьи. Один из самых быстрых способов — через оболочку. Позже мы сделаем это из панели администратора или с помощью специальной формы, которую мы создадим. Вы можете догадаться, что мы делаем это снова с manage.py: python manage.py shell:

Это дает нам простой и быстрый способ взаимодействия с нашим веб-сайтом без написания какого-либо представления и контроллера для проверки чего-либо. Мое основное использование — сделать что-то вроде проверки запроса, такого как фильтр или получение. Мы можем быстро взаимодействовать через оболочку, а не распечатывать, регистрировать или отображать данные в представлении. Когда у нас много связанных моделей, написание кода, который делает то, что мы хотим, не всегда получается с первого раза. Я предпочитаю запускать свой веб-сайт в режиме отладчика, где мне удобнее тестировать вещи. Но давайте посмотрим на быстрый пример; давайте импортируем нашу модель Article и ArticleSeries:

Теперь мы можем просмотреть нашу модель, чтобы увидеть, какая запись у нас есть:

Мы видим, что в базу данных была вставлена ​​новая запись. Круто, а?

Однако все может стать более сложным, когда у нас будет гораздо больше объектов, поэтому я бы не рекомендовал использовать оболочку для вставки данных. Можете ли вы представить себе написание целых статей или серий через оболочку?! Вместо этого мы, скорее всего, будем использовать для этого страницу администратора, которую мы обсудим в будущем уроке!

Заключение:

В этом руководстве мы научились определять модели и использовали эту информацию для создания и реализации соответствующих моделей для базового веб-сайта Django.

А пока мы ненадолго отвлечемся от создания основного приложения и сайта. В настоящее время нет веб-сайтов, на которых у нас не было бы информации о Пользователях. Итак, наша следующая цель туториала будет заключаться в том, чтобы охватить лучший способ создания пользователей, чтобы мы могли гибко использовать его в будущем.

Эти обучающие файлы можно загрузить с GitHub.

Первоначально опубликовано на https://pylessons.com/django-using-models

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.