Классовые представления в Django: частые ошибки

Класс-представление на пять строк выглядит безобидно, пока не начинаешь его дорабатывать. Вы переопределяете get_context_data и теряете половину контекста. Ставите LoginRequiredMixin справа от ListView — и проверка авторизации не срабатывает. Фильтруете queryset атрибутом класса — и один пользователь видит данные другого. Всё это не падает с ошибкой: страница открывается, просто показывает не то. Ниже — разбор ошибок, которые чаще всего всплывают в class-based views на Django 4.2 и 5.x, с ценой каждой и с тем, как писать правильно.

Материал для тех, кто уже пишет CBV и упёрся в конкретное поведение. Если вы только знакомитесь с представлениями, начните с function-based views — там меньше магии наследования.

1. Забыли super() в get_context_data

Самая частая ошибка новичков в CBV. Вы хотите добавить в шаблон одну переменную и пишете так:

class ArticleDetailView(DetailView):
    model = Article

    # Ошибка: возвращаем только свой ключ, теряем object и остальное
    def get_context_data(self, **kwargs):
        return {"related": Article.objects.all()[:5]}

Шаблон перестаёт видеть object и article, которые DetailView кладёт в контекст сам. Симптом — пустая страница детали при рабочей вьюхе. Правильно всегда начинать с вызова родителя:

class ArticleDetailView(DetailView):
    model = Article

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["related"] = Article.objects.all()[:5]
        return context

Цена ошибки: полчаса на выяснение, почему в шаблоне пусто, при том что вьюха отрабатывает без исключений.

2. queryset как атрибут класса вместо get_queryset

Атрибут queryset вычисляется один раз — при импорте модуля, когда класс загружается. Для фильтрации по текущему пользователю или по дате это ловушка:

class MyOrdersView(ListView):
    # Опасно: request здесь недоступен, а now() зафиксируется на момент старта процесса
    queryset = Order.objects.filter(created__gte=timezone.now())

Второй вариант этой же ошибки страшнее. Если вам нужно показать заказы текущего пользователя, атрибут этого сделать не может — self.request в момент определения класса не существует. Люди пытаются обойти это и получают вьюху, которая всем показывает одну и ту же выборку. Всё, что зависит от запроса, времени или сессии, — только в методе:

class MyOrdersView(LoginRequiredMixin, ListView):
    def get_queryset(self):
        # Вызывается на каждый запрос, self.request доступен
        return Order.objects.filter(user=self.request.user)

Правило простое: атрибут queryset — для статичных выборок, которые одинаковы для всех и не меняются во времени. Всё остальное — в get_queryset. Спутать их — значит рано или поздно показать одному пользователю данные другого.

3. Миксин авторизации справа от базового View

Порядок наследования в Python определяет MRO — порядок разрешения методов^*. Миксины проверки доступа работают, только если стоят левее основного класса представления. Иначе их dispatch не попадёт в цепочку раньше базового.

# Неправильно: LoginRequiredMixin справа — проверка может не сработать
class SecretView(TemplateView, LoginRequiredMixin):
    template_name = "secret.html"

# Правильно: миксин первым
class SecretView(LoginRequiredMixin, TemplateView):
    template_name = "secret.html"

Цена: страница, которую вы считали закрытой, открывается анониму. Это не косметика, а дыра в доступе. Проверить порядок можно, распечатав SecretView.__mro__ — все миксины доступа должны идти до View.

4. Дублирование логики между get и post

В FormView и CreateView легко продублировать выборку или проверку в get и post. Через месяц правку в одном месте забывают внести в другое. Общую подготовку выносите в dispatch или в отдельный метод:

class OrderEditView(LoginRequiredMixin, UpdateView):
    model = Order
    fields = ["comment"]

    def dispatch(self, request, *args, **kwargs):
        # Выполнится и для GET, и для POST, до основной логики
        self.order = get_object_or_404(Order, pk=kwargs["pk"], user=request.user)
        return super().dispatch(request, *args, **kwargs)

Теперь проверка владельца заказа гарантированно срабатывает на любой метод, а не только когда вы про неё вспомнили.

5. get_object без учёта прав

По умолчанию DetailView и UpdateView достают объект по pk из URL без всяких проверок. Если объект приватный, любой, кто подставит чужой id, получит доступ. Фильтруйте get_queryset, а не get_object:

class DocumentDetailView(LoginRequiredMixin, DetailView):
    model = Document

    def get_queryset(self):
        # get_object() возьмёт pk уже из суженного queryset
        # чужой документ вернёт 404, а не 403 с утечкой факта существования
        return Document.objects.filter(owner=self.request.user)

Сводка: атрибут или метод

Когда что выбирать: CBV или FBV

Class-based views выигрывают на типовых CRUD-сценариях, где generic-классы закрывают 80% работы. Как только вьюха обрастает тремя переопределёнными методами и двумя миксинами — читаемость падает, и function-based view с явным if request.method == "POST" часто честнее. Не тащите CBV туда, где логика ветвится нелинейно.

• CBV — список, деталь, форма создания и редактирования, где поведение близко к стандартному.
• FBV — вьюха с нетривиальным ветвлением, вебхуки, эндпоинты со сложной обработкой запроса, где наследование только запутывает.

Что делать дальше

Пройдитесь по своим представлениям с этим чек-листом: все ли get_context_data вызывают super(), нигде ли фильтрация по пользователю не висит в атрибуте queryset, стоят ли миксины доступа левее базового класса. Распечатайте __mro__ для вьюх с несколькими миксинами и убедитесь, что порядок тот, что вы ожидаете. Инвалидация кеша во вьюхах и работа с DRF-дженериками — отдельные темы, здесь мы разбирали только классические Django CBV.

Полный справочник методов каждого generic-класса лежит в документации Django на classy-class-based-views — там видно, какой метод в каком порядке вызывается.