Class-based views were introduced in Django 1.4. Here is how the previous view looks when rewritten to be a functionally equivalent class-based view:

from django.views.generic import View 
 
 
class HelloView(View): 
    def get(self, request, name="World"): 
        return HttpResponse("Hello {}!".format(name)) 

Again, the corresponding URLConf would have two lines, as shown in the following commands:

# In urls.py 
    path('hello-cl/<str:name>/', views.HelloView.as_view()), 
    path('hello-cl/', views.HelloView.as_view()),

There are several interesting differences between this View class and our earlier view function. The most obvious one being that we need to define a class. Next, we explicitly define that we will handle only the GET requests. The previous view function gives the same response for GET, POST, or any other HTTP verb, as shown in the following commands using the test client in a Django shell:

>>> from django.test import Client
>>> c = Client()

>>> c.get("http://0.0.0.0:8000/hello-fn/").content
b'Hello World!'

>>> c.post("http://0.0.0.0:8000/hello-fn/").content
b'Hello World!'

>>> c.get("http://0.0.0.0:8000/hello-cl/").content
b'Hello World!'

>>> c.post("http://0.0.0.0:8000/hello-cl/").content
Method Not Allowed (POST): /hello-cl/
b''

Notice that the POST method is disallowed rather than being silently ignored. Being explicit is good from a security and maintainability point of view.

The biggest advantage of using a class will be clear when you need to customize your view. Say you need to change the greeting and the default name. Then, you can write a general View class for any kind of greeting and derive your specific greeting classes as follows:

class GreetView(View): 
    greeting = "Hello {}!" 
    default_name = "World" 
    def get(self, request, **kwargs): 
        name = kwargs.pop("name", self.default_name) 
        return HttpResponse(self.greeting.format(name)) 
 
class SuperVillainView(GreetView): 
    greeting = "We are the future, {}. Not them. " 
    default_name = "my friend" 

Now, the URLConf would refer to the derived class:

# In urls.py 
    path('hello-su/<str:name>/', views.SuperVillainView.as_view()), 
    path('hello-su/', views.SuperVillainView.as_view()),     

While it is not impossible to customize the view function in a similar manner, you would need to add several keyword arguments with default values. This can quickly get unmanageable. This is exactly why generic views migrated from view functions to class-based views.