Django CBVs seem overwhelming, because there are so many!

When learning about class-based views in Django, it’s easy to get overwhelmed. Dealing with the topic, you’re bound to face not just the View class, but all of the generic class-based views out there. This can lead to choice paralysis, and make getting started with CBVs harder than it should be.

You don’t need to deal with generic class-based views

First of all, it’s important to distinguish between class-based views (CBVs) and generic class-based views (gCBVs). It’s pretty common to mix up the concept of CBVs with gCBVs in general.

Just ignore all generic CBVs, and stick to the View base class! You don’t need to use anything other to use CBVs and make your project work.

gCBVs are not mandatory when using CBVs

Generic class-based views, are supposed to save time for people who already have an overview and are trying to accomplish a generic task.

If you’re new to Django, or new to using class based views, it’s completely acceptable to stick to building on top of the View class. I’d go as far, as saying that it’s recommended when starting out and the best choice if you feel overwhelmed.

You can always come back to learn more about one or two useful generic class-based views when you find yourself writing the same simple types of views eventually. But until then, there’s nothing wrong with having a bit of similar-looking code in your project.

Getting started with CBVs

Here’s a simply example, which is good enough for everything you might want to build with CBVs:

from django.shortcuts import render
from django.views import View

class TestViewCBV(View):
    def get(self, request):
        template_name = 'test.html'
	# this data dict will be added to the template context
        data = {}
        data["message"] = "Hi!"
        return render(request, template_name, data)

    def post(self, request):
	# we don't handle POST requests
        pass

As you can see, this class has two functions: one will be used for GET requests, and the other for POST requests. Inside of those functions, you can use the request and return a rendered template, just as you might with FBVs. The only difference is, that you don’t need a bit if-else statement to distinguish between different HTTP verbs, as you would in a FBV.

In conclusion

If you’re overwhelmed by the sheer number of generic class-based Views out there, and find it hard to get started using CBVs, that’s because you are mixing up two different things. Writing CBVs does not mean you have to learn all gCBV by heart first, and bend them to your will at any possible opportunity.

Just stick to the CBV concept and leave gCBVs be for now. Try writing your views based on the View class, and ignore all of the gCBVs for now.

Doing so is not discouraged, nor in bad taste. It will help you to get a feeling for class-based views when starting out. This way, you will make progress on your project without getting lost in unnecessary code optimization at an inappropriate moment.

If you want to see a comparison between FBVs, CBVs and gCBVs - take a look at this article.