既然已有Class-based views，为何仍需使用Function-based views？

Great question! Even though Django's class-based views—especially generic CBVs with their mixin system—offer powerful, reusable tools for common development patterns, function-based views (FBVs) still have an important place in Django projects. Let’s break down why they’re still relevant:

Simplicity for Straightforward Use Cases #

FBVs were Django’s original view pattern, and for simple, one-off tasks that don’t fit neatly into generic CBV templates, they’re often faster to write and easier to understand. Think of a basic static page, a simple form submission with minimal logic, or a view that just returns a JSON response. You don’t need to mess with class inheritance or mixins here—just write a plain Python function that takes a request object, does its work, and returns an HttpResponse.

For example:

def contact_thank_you(request):
    return render(request, 'contact/thank_you.html', {'message': 'Your inquiry has been sent!'})

This code is straightforward even for someone new to Django, whereas using a TemplateView for the same task adds unnecessary boilerplate.

Easier Debugging and Execution Traceability #

FBVs follow a linear execution flow—your code runs top to bottom, so when debugging, it’s simple to trace exactly what’s happening step by step. With CBVs, you might have to dig through multiple parent classes and mixins to figure out where a particular piece of logic is coming from, which can be confusing, especially if you’re still getting comfortable with Django’s CBV ecosystem.

Full Control for Unorthodox Logic #

CBVs excel at standard patterns like list/detail views, form handling, or authentication flows. But if your view has highly custom, non-standard logic that doesn’t play well with the mixin system, FBVs give you complete flexibility. You don’t have to force a CBV to fit your needs—you can structure the code exactly how you want, without dealing with method overriding conflicts or navigating complex inheritance hierarchies.

For example, handling multiple HTTP methods in a non-standard way is trivial with FBVs:

def custom_resource(request):
    if request.method == 'GET':
        return render(request, 'resource/view.html', {'data': get_resource()})
    elif request.method == 'POST':
        process_custom_post_data(request.POST)
        return redirect('resource_success')
    elif request.method == 'PUT':
        update_resource(request.body)
        return HttpResponse(status=200)

Doing this with CBVs would require overriding multiple methods or finding a mixin that fits, which adds unnecessary complexity.

Gentler Learning Curve for New Developers #

For someone just starting with Django, FBVs are far easier to grasp. They build on basic Python function knowledge that most developers already have, avoiding the need to understand OOP concepts like mixins, method resolution order, or class inheritance right out the gate. It’s a great way to learn how Django handles requests and responses before moving on to the more powerful but complex CBV system.

A Quick Bit of Context #

To tie this back to Django’s history: originally, FBVs were the only option. Later, function-based generic views were introduced to abstract common patterns, but they lacked extensibility. Class-based generic views came next to solve that problem with mixins, offering more flexibility for standard use cases. But FBVs never became obsolete because they fill a unique niche for simplicity and custom control.

At the end of the day, it’s not about choosing one over the other—it’s using the right tool for the job. CBVs are perfect for reusable, standard patterns, while FBVs shine for simple tasks, custom logic, or when you want full control over your view’s execution flow.

内容的提问来源于stack exchange，提问作者Jora Karyan