Какую роль выполняют модели в Django

Ответ

Модель в Django — это Python-класс, который является единственным и окончательным источником данных о структуре таблицы в базе данных. Модели позволяют работать с БД через ORM (Object-Relational Mapping), используя Python-код вместо написания SQL-запросов.

Каждый класс модели соответствует таблице в БД, а каждый его атрибут (поле) — столбцу в этой таблице.

Пример модели

from django.db import models

# Этот класс будет преобразован в таблицу 'yourapp_article'
class Article(models.Model):
    # Атрибуты станут столбцами в таблице с определенными типами данных
    title = models.CharField(max_length=200, verbose_name="Заголовок")
    content = models.TextField(verbose_name="Содержимое")
    published_at = models.DateTimeField(auto_now_add=True, verbose_name="Дата публикации")
    is_published = models.BooleanField(default=True, verbose_name="Опубликовано")

    def __str__(self):
        return self.title

    class Meta:
        verbose_name = "Статья"
        verbose_name_plural = "Статьи"

Ключевые возможности

  • Абстракция от БД: Позволяют работать с записями как с объектами Python, скрывая сложность SQL.
  • Миграции: Django автоматически отслеживает изменения в моделях и генерирует файлы миграций для безопасного обновления схемы базы данных (makemigrations и migrate).
  • Валидация данных: Поля моделей (CharField, IntegerField и др.) предоставляют встроенные механизмы валидации.
  • API для запросов: Предоставляют мощный и гибкий API для выполнения CRUD-операций (создание, чтение, обновление, удаление).
    # Пример запроса
    Article.objects.filter(is_published=True).order_by('-published_at')

Ответ 18+ 🔞

А, ну ты смотри, модель в Django — это такая, блядь, священная корова, единственный и окончательный источник правды о том, как твоя таблица в базе данных устроена. Вместо того чтобы писать эти ёбаные SQL-запросы, где запятую не там поставишь и всё, пиздец, ты просто пишешь на Python, а ORM всё за тебя делает. Магия, сука, но магия понятная.

Каждый такой класс — это таблица, а каждый его атрибут — это столбец. Всё просто, как три копейки, если не усложнять.

Смотри, как это выглядит

from django.db import models

# Этот класс станет таблицей 'yourapp_article'. Всё, приехали.
class Article(models.Model):
    # Вот эти штуки — это и есть твои колонки. Тип данных, ограничения — всё тут.
    title = models.CharField(max_length=200, verbose_name="Заголовок")
    content = models.TextField(verbose_name="Содержимое")
    published_at = models.DateTimeField(auto_now_add=True, verbose_name="Дата публикации")
    is_published = models.BooleanField(default=True, verbose_name="Опубликовано")

    def __str__(self):
        return self.title  # Чтобы в админке не `Article object (1)`, а что-то человеческое

    class Meta:
        verbose_name = "Статья"
        verbose_name_plural = "Статьи"  # А то будут "Статьяs", ёпта

Что за фишки тут есть, и почему это охуенно

  • Не паришься про БД: Работаешь с записями как с обычными питонячьими объектами. Хочешь добавить запись? Создаёшь экземпляр класса и save(). SQL? Не, не слышал.
  • Миграции — твои лучшие друзья и одновременно кошмар: Добавил поле в модель? Django это видит. Потом пишешь makemigrations — он создаёт инструкцию «как изменить базу». Потом migrate — применяет её. Главное, на проде не обосраться, проверяя миграции. А то бывало, блядь...
  • Данные сами себя проверяют: Поле CharField не даст запихнуть туда текст длиннее, чем max_length. IntegerField — только числа. Не надо самому писать кучу if-ов, чтобы отсеять хуйню.
  • Запросы — просто песня: Хочешь выбрать все опубликованные статьи, отсортированные по дате? Пожалуйста, на, еби себе мозг SQL-ем:

    # Берём все статьи, где is_published=True, и сортируем от новых к старым. Красота!
    Article.objects.filter(is_published=True).order_by('-published_at')

В общем, модель — это фундамент. Сделал её правильно — жить будешь долго и счастливо. Накосячил — потом будешь, блядь, волосы на жопе рвать, переделывая связи и миграции. Думай головой, когда поля называешь!