Как надо. Django View

Этот текст — история любви к CBV (Class-Based Views). По своей сути представление на основе классов позволяет вам отвечать на различные методы HTTP-запросов с помощью различных методов экземпляра класса, а не с помощью условного ветвления кода внутри одной функции представления.

Просто для примера как выглядит CBV представление, которое будет отображать список всех статей.

from django.views.generic import ListView
from .models import Article  # Импортируем модель Article

class ArticleListView(ListView):
    model = Article  # Указываем модель, с которой работает представление
    template_name = 'article_list.html'  # Имя шаблона для отображения
    context_object_name = 'articles'  # Имя переменной контекста в шаблоне
    ordering = ['-published_date']  # Сортировка статей по дате публикации (сначала новые)
    paginate_by = 10  # По 10 статей на странице

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context['total_articles'] = Article.objects.count()  # Добавляем общее количество статей
        return context

… и соответственно шаблон для “вьюхи”

<!DOCTYPE html>
<html>
<head>
    <title>Список статей</title>
</head>
<body>
    <h1>Список статей</h1>
    <ul>
        
    </ul>
</body>
</html>

По мне так комментарии излишни.

  • Минимальный код для отображения списка объектов.
  • Гибкость через переопределение методов (get_queryset, get_context_data и др.).
  • Поддержка пагинации.

Почему Class-Based Views (CBV) предпочтительнее чем Function-Based Views (FBV)

  1. Повторное использование кода
    CBV позволяют легко повторно использовать код через наследование. Вы можете создать базовый класс с общей логикой и наследовать его в других представлениях. С FBV это сделать сложнее, так как придется копировать код или использовать декораторы.
  2. Структурированность
    CBV разделяют логику для разных HTTP-методов (GET, POST, PUT, DELETE и т.д.) на отдельные методы (get(),post()и др.). Это делает код более организованным и читаемым. С FBV пришлось бы использовать условные операторы.
  3. Встроенная функциональность
    Django предоставляет множество готовых Generic Class-Based Views (например, ListView, DetailView, CreateView, UpdateView, DeleteView), которые значительно упрощают работу с моделями, формами и шаблонами. С FBV эту логику пришлось бы писать вручную. С FBV пришлось бы вручную писать логику для запроса к базе данных и передачи данных в шаблон.
  4. Миксины
    CBV поддерживают миксины, которые позволяют добавлять функциональность в представления без дублирования кода. Например, можно добавить проверку аутентификации или прав доступа с помощью миксинов.
  5. Повторное использование методов
    CBV позволяют переопределять методы (например, get_context_data(), get_queryset()), чтобы добавить или изменить поведение представления. Это делает код более модульным.
  6. Лучшая поддержка тестирования
    CBV легче тестировать, так как их методы (get(), post()и др.) изолированы и могут быть протестированы отдельно.

Есть ли смысл в использовании FBV. Да. Если вы стремитесь полностью контролировать свою логику, особенно когда сталкиваетесь с нестандартными задачами, то вам стоит обратить внимание на FBV. Или более банальный случай. Вам сложно понять всю эту магию из наследований и встроенной логики, и CBV реально затруднителен для новичков.

В любом случае, эти два подхода будут с нами ещё долго.

Список типов CBV

В Django существует несколько типов CBV, которые можно разделить на несколько категорий в зависимости от их назначения. Вот основные категории и их реализации:

  1. Базовые классы представлений
    View — базовый класс для создания собственных представлений. Он предоставляет минимальную функциональность.
    TemplateView — используется для отображения шаблонов.
    RedirectView — выполняет перенаправление на указанный URL.

  2. Представления для работы с данными (Generic Display Views)
    DetailView — отображает детальную информацию об одном объекте модели.
    ListView — отображает список объектов модели.

  3. Представления для редактирования данных (Generic Edit Views)
    FormView — обрабатывает формы.
    CreateView — используется для создания новых объектов модели.
    UpdateView — используется для редактирования существующих объектов модели.
    DeleteView — используется для удаления объектов модели.

  4. Представления для работы с датами (Date-Based Views)
    ArchiveIndexView — отображает архив объектов с группировкой по дате.
    YearArchiveView — отображает объекты за определенный год.
    MonthArchiveView — отображает объекты за определенный месяц.
    WeekArchiveView — отображает объекты за определенную неделю.
    DayArchiveView — отображает объекты за определенный день.
    TodayArchiveView — отображает объекты за сегодняшний день.
    DateDetailView — отображает детальную информацию об объекте с учетом даты.

  5. Миксины (Mixins)
    LoginRequiredMixin — требует аутентификации пользователя.
    PermissionRequiredMixin — проверяет наличие прав у пользователя.
    FormMixin — добавляет функциональность работы с формами.
    SingleObjectMixin — добавляет функциональность работы с одним объектом модели.

  6. Другие специализированные представления
    TemplateResponseMixin — используется для работы с шаблонами.
    ContextMixin — добавляет контекст в шаблон.
    MultipleObjectMixin — используется для работы с несколькими объектами модели.

Количество реализаций Class-Based Views в Django достаточно велико, и они охватывают практически все возможные сценарии работы с представлениями. Их можно комбинировать и расширять для создания сложной логики представлений. Не уверен что перечислил всё, но у вас есть всегда возможность обратиться к официальной документации.