Comme nous le savons tous, Django utilise MVT (model-view-template) pour sa conception sur le développement d'applications Web.

View lui-même est un appelable qui prend une requête et renvoie une réponse. c'est plus qu'une simple fonction car Django fournit quelque chose appelé vue basée sur les classes, afin que le développeur puisse écrire une vue en utilisant, eh bien, une approche basée sur les classes ou vous pouvez dire une approche POO. Cette vue basée sur les classes est conçue pour que nous puissions structurer nos vues et puisse être réutilisée grâce à la puissance de l'héritage et des mixins.

Comme cela est bien documenté dans la documentation Django, l'un des problèmes de la vue basée sur les fonctions est qu'il n'existe aucun moyen de les étendre ou de les personnaliser au-delà de certaines options de configuration, ce qui limite leur utilité dans de nombreuses applications du monde réel.

La boîte à outils des classes de base et des mixins dans Django est conçue pour une flexibilité maximale. Voyons comment nous pouvons utiliser la vue basée sur les classes la plus basique dans Django en utilisant l'héritage de classe View et comparons-le à la vue basée sur les fonctions.

#views.py using View class inheritance
from django.views import View
from django.http import HttpResponse, HttpRequest

class IndexView(View):
    def get(self, request: HttpRequest):
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from indexview")

    def post(self, request: HttpRequest):
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from indexview in post method")

#views.py function based view
from django.http import HttpResponse, HttpRequest

def index(request: HttpRequest):
    if request.method == "GET":
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from index funcion view")
    elif request.method == "POST":
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from index funcion view in post method")

Si vous regardez ci-dessus, une vue basée sur les classes vous permet de répondre à différentes méthodes de requête HTTP avec différentes méthodes d'instance de classe, au lieu d'utiliser du code de branchement conditionnel dans une seule fonction de vue. imaginez maintenant dans chaque vue ci-dessus que nous avons ajouté 10 lignes de logique à chaque méthode, vous devriez pouvoir savoir laquelle est la plus facile à parcourir.

Afin d'enregistrer la vue basée sur la classe dans la configuration de l'URL, nous devons appeler la méthode de classe as_view() qui convertira essentiellement la vue de classe en une fonction appelable. cette fonction convertie appellera setup() pour initialiser son attribut, puis appelle dispatch() pour vérifier quelle méthode l'utilisateur possède (une méthode GET, POST ou autre) et connectera la méthode de requête à la méthode de correspondance correspondante que la vue basée sur la classe avait à l'origine

#urls.py

from django.urls import path
from myapp.views import IndexView, index

urlpatterns = [
    path("", IndexView.as_view(), name=IndexView.__name__), 
    path("index/", index, name=index.__name__),

]

La vue basée sur les classes prend également en charge tous les raccourcis http de Django, tels que la fonction render() pour restituer un modèle, voici un exemple modifié de Django cbv utilisant le raccourci de rendu et coopérant avec le framework de messages Django

class IndexView(View):
    def get(self, request: HttpRequest):
        # imagine 10 line of view logic here
        return render(request, "GEtindex.html")

    def post(self, request: HttpRequest):
        # imagine 10 line of view logic here
        messages.add_message(request, messages.INFO, "POST Success") #add display success message here by django messages framework
        return render(request, "POSTindex.html")

Dans l'ensemble, la vue basée sur la classe Django permet au développeur de mieux écrire pour comprendre la logique de la vue, plus une logique de vue est complexe, je suis presque sûr qu'elle sera plus difficile à lire si nous utilisons simplement une vue basée sur les fonctions (trop d'instructions if pour vérifier quoi (la méthode est utilisée par l'utilisateur à titre d'exemple) et difficile à mettre à l'échelle, tandis que Django cbv est conçu pour diviser notre logique de vue en plusieurs méthodes telles que les méthodes get et post. et peut être réutilisé dans l'héritage si vous le souhaitez, même si je peux affirmer que plus nous avons d'héritage dans une classe, il sera plus difficile à lire en raison de son abstraction.

vous pouvez en savoir plus sur la vue basée sur les classes dans la documentation Django à partir d'ici, ici, ici

Ccbv.co.uk est également un bon document alternatif qui se concentre sur la vue basée sur la classe Django