Why Django CBVs Feel Confusing - And How to Stop Fighting Them

PROFESSIONAL DJANGO ENGINEERING SERIES #7

The MRO is not magic. Once you understand what dispatch() does and why mixin order matters, class-based views become entirely predictable.

Class-based views are one of Django’s most divisive features. Some developers swear by them. Others find them opaque, hard to debug, and more trouble than they are worth. Both camps have a point.

The difference, in my experience, is almost always understanding. Developers who find CBVs confusing are typically using them without understanding three things: what dispatch() does, how Python’s MRO determines which method gets called, and why mixin order is not arbitrary.

Once those three things click, CBVs become predictable. Let me show you each one.

The problem with class-based views is not that they are complex. It is that their complexity is hidden. A function-based view shows you everything. A class-based view shows you only what you override — the rest is inherited, and inheritance is invisible until it breaks.

What Actually Happens When Django Calls a CBV

Start with the fundamentals. When Django matches a URL to a class-based view, here is the exact execution sequence:

# In urls.py:
path('orders/', OrderListView.as_view(), name='order-list')

# as_view() is called ONCE at startup (not per request).
# It returns a function. That function is called on every request.

# What as_view() returns, simplified:
def view(request, *args, **kwargs):
    self = OrderListView()          # 1. Instantiate the class
    self.setup(request, *args, **kwargs)  # 2. Attach request, args, kwargs
    return self.dispatch(request, *args, **kwargs)  # 3. Route to handler

# dispatch() looks like this:
def dispatch(self, request, *args, **kwargs):
    if request.method.lower() in self.http_method_names:
        handler = getattr(self, request.method.lower())  # get(), post(), etc.
    else:
        handler = self.http_method_not_allowed
    return handler(request, *args, **kwargs)

Three things are worth noting here:

• A new instance is created for every request. Instance variables are safe to use within a single request lifecycle.
• The dispatch() method is the first method called after setup(). It is the correct place for cross-cutting logic that applies regardless of HTTP method.
• as_view() runs once at startup. Any logic you put there runs once, not per request. Do not use it for per-request initialisation.

The Method Resolution Order: Why Mixin Order Is Not Arbitrary

Python resolves method calls using the Method Resolution Order (MRO): a linearization of the class hierarchy that determines which class’s version of a method is called when multiple classes define it.

For CBVs with multiple mixins, the MRO governs everything. Getting the order wrong produces subtle, hard-to-debug failures — not errors, just wrong behaviour.

# MRO is determined left-to-right, then up the hierarchy
class MyView(LoginRequiredMixin, PermissionRequiredMixin, DetailView):
    ...

# MRO: MyView -> LoginRequiredMixin -> PermissionRequiredMixin -> DetailView -> View

# When dispatch() is called:
# 1. Python looks in MyView          — not defined
# 2. Python looks in LoginRequiredMixin — FOUND
#    LoginRequiredMixin.dispatch() checks authentication.
#    If user is not logged in: redirect to login.
#    If user is logged in: calls super().dispatch()
# 3. super() resolves to PermissionRequiredMixin
#    Checks the required permission. Denies or calls super().
# 4. super() resolves to DetailView
#    Runs the actual view logic.

# WRONG ORDER: DetailView runs before authentication is checked
class MyView(DetailView, LoginRequiredMixin):  # Never do this
    ...

The rule: access-control mixins always go leftmost. They must intercept dispatch() before any view logic runs. If they are not leftmost, the view logic executes first — unauthenticated.

Writing a Mixin Correctly: The super() Contract

The single most common CBV mistake is forgetting super() in a mixin method. This silently breaks the entire chain.

# BROKEN: forgetting super() discards every other mixin's contribution
class OrganisationMixin:
    def get_context_data(self, **kwargs):
        context = {}  # starts fresh, throws away everything else
        context['organisation'] = self.request.user.organisation
        return context
    # Result: template receives only 'organisation', nothing else.
    # No 'object', no 'page_obj', no pagination — all silently discarded.

# CORRECT: always call super() and use its return value
class OrganisationMixin:
    def get_queryset(self):
        qs = super().get_queryset()      # get the base queryset first
        return qs.filter(organisation=self.request.user.organisation)

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)  # build the full context
        context['organisation'] = self.request.user.organisation
        return context

⚠ The Silent Context Killer: A mixin that overrides get_context_data() without calling super() silently discards every other mixin's context contributions. The view renders without errors. The template receives partial context. The bug is almost invisible because there is no exception — only missing data. Make it a rule: every CBV hook that you override (dispatch, get, post, get_queryset, get_context_data, get_object, form_valid) must call super() and use its return value. Every single one.

The Generic Views: Using Them Correctly

ListView: Scope the Queryset

from django.views.generic import ListView
from django.contrib.auth.mixins import LoginRequiredMixin

class OrderListView(LoginRequiredMixin, ListView):
    model               = Order
    template_name       = 'orders/list.html'
    context_object_name = 'orders'
    paginate_by         = 20
    ordering            = ['-created_at']

    def get_queryset(self):
        # Always call super() to respect model, ordering, etc.
        qs = super().get_queryset()
        return (
            qs
            .filter(user=self.request.user)
            .select_related('user', 'shipping_address')
            .prefetch_related('items__product')
        )

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        # self.object_list is the paginated queryset, already in context.
        # Add extra data here.
        context['pending_count'] = (
            Order.objects.filter(user=self.request.user, status='pending').count()
        )
        return context

DetailView: Scope for Authorization

from django.views.generic import DetailView

class OrderDetailView(LoginRequiredMixin, DetailView):
    model               = Order
    template_name       = 'orders/detail.html'
    context_object_name = 'order'
    pk_url_kwarg        = 'order_id'

    def get_queryset(self):
        # CRITICAL: scope to current user.
        # If another user tries to access an order ID that exists
        # but belongs to someone else, get_object() raises Http404.
        # No if/raise needed — the queryset scope handles it.
        return (
            Order.objects
            .filter(user=self.request.user)
            .select_related('user', 'shipping_address')
            .prefetch_related('items__product')
        )

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        # self.object is set before get_context_data() is called
        context['can_cancel'] = self.object.status == Order.Status.PENDING
        return context

The dispatch() Hook: Cross-Cutting Concerns

For logic that must run regardless of HTTP method — rate limiting, audit logging, feature flags — override dispatch() in a mixin:

class AuditLogMixin:
    """Log every request to this view for compliance audit."""

    def dispatch(self, request, *args, **kwargs):
        import logging
        logger = logging.getLogger('audit')
        logger.info('view_accessed', extra={
            'user':   request.user.id,
            'method': request.method,
            'path':   request.path,
            'view':   self.__class__.__name__,
        })
        return super().dispatch(request, *args, **kwargs)


# Compose: audit + auth + view
class SensitiveDataView(AuditLogMixin, LoginRequiredMixin, DetailView):
    model         = FinancialRecord
    template_name = 'records/detail.html'
    # By the time get() runs: audited and authenticated.

When to Use a Function-Based View Instead

CBVs are not the answer to every problem. Use a function-based view when:

• The view has non-standard control flow. Three different HTTP methods with completely different logic is often cleaner as an FBV with explicit if/elif than as a CBV juggling three method handlers.
• The view is a one-off with no reuse. A webhook endpoint, a health check, an OAuth callback. The CBV machinery adds nothing when there is nothing to reuse.
• The generic view behaviour actively fights you. If you are overriding get_queryset, get_object, get_context_data, form_valid, and get_success_url simultaneously, you have written an FBV with extra steps. Accept that and write the FBV.

The choice between CBV and FBV should be driven by the shape of the problem, not by convention or habit.

✓ Key Takeaways:

• as_view() runs once at startup. A new instance is created for every request. dispatch() is the first method called. Override it in mixins for cross-cutting concerns.
• Access-control mixins (LoginRequired, Permission) always go leftmost in the class definition.
• Every CBV hook you override must call super() and use its return value. Every one.
• Scope get_queryset() to the current user for authorization. Django raises Http404 automatically.
• FBVs are not a fallback. They are the correct tool for non-standard control flow and one-off endpoints.