Wie wir alle wissen, verwendet Django MVT (Model-View-Template) für sein Design bei der Entwicklung von Webanwendungen.

View selbst ist ein Callable, das eine Anfrage entgegennimmt und eine Antwort zurückgibt. Es ist mehr als nur eine Funktion, da Django eine sogenannte klassenbasierte Ansicht bereitstellt, sodass Entwickler eine Ansicht mithilfe eines klassenbasierten Ansatzes oder, sagen wir, eines OOP-Ansatzes schreiben können. Diese klassenbasierte Ansicht ist so konzipiert, dass wir unsere Ansichten strukturieren und mithilfe von Vererbung und Mixins wiederverwenden können.

Wie in den Django-Dokumenten gut dokumentiert, besteht eines der Probleme bei funktionsbasierten Ansichten darin, dass es keine Möglichkeit gibt, sie über einige Konfigurationsoptionen hinaus zu erweitern oder anzupassen, was ihren Nutzen in vielen realen Anwendungen einschränkt.

Das Toolkit der Basisklassen und Mixins in Django ist auf maximale Flexibilität ausgelegt. Schauen wir uns an, wie wir mithilfe der View-Klassenvererbung die grundlegendste klassenbasierte Ansicht in Django verwenden und sie mit der funktionsbasierten Ansicht vergleichen können.

#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")

Wie Sie oben sehen, können Sie mit einer klassenbasierten Ansicht auf verschiedene HTTP-Anforderungsmethoden mit unterschiedlichen Klasseninstanzmethoden antworten, anstatt Code innerhalb einer einzelnen Ansichtsfunktion bedingt zu verzweigen. Stellen Sie sich nun vor, dass wir in jeder Ansicht oben 10 Logikzeilen für jede Methode hinzugefügt haben. Sie sollten erkennen, welche davon einfacher zu durchlaufen ist.

Um die klassenbasierte Ansicht in der URL-Konfiguration zu registrieren, müssen wir die Klassenmethode as_view() aufrufen, die die Klassenansicht grundsätzlich in eine aufrufbare Funktion umwandelt. Diese konvertierte Funktion ruft setup() auf, um ihr Attribut zu initialisieren, und ruft dann „dispatch()“ auf, um zu überprüfen, welche Methode der Benutzer hat (GET, POST oder eine andere Methode) und verbindet die Anforderungsmethode mit der entsprechenden passenden Methode, die die klassenbasierte Ansicht ursprünglich hatte

#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__),

]

Die klassenbasierte Ansicht unterstützt auch alle HTTP-Shortcuts, die Django hat, z. B. die Funktion render() zum Rendern einer Vorlage. Hier ist ein modifiziertes Beispiel für Django CBV, das die Render-Verknüpfung verwendet und mit dem Django-Nachrichten-Framework zusammenarbeitet.

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")

Insgesamt ermöglicht die auf einer Django-Klasse basierende Ansicht dem Entwickler, besser zu schreiben, um die Ansichtslogik zu verstehen. Je komplexer eine Ansichtslogik ist, ich bin mir ziemlich sicher, dass sie schwieriger zu lesen sein wird, wenn wir nur eine funktionsbasierte Ansicht verwenden (zu viele if-Anweisungen, um zu überprüfen, was). Die Methoden werden beispielsweise vom Benutzer verwendet) und sind schwer zu skalieren. Django cbv hingegen ist darauf ausgelegt, unsere Ansichtslogik in mehrere Methoden wie die Get- und Post-Methode zu unterteilen. und kann bei Bedarf erneut in der Vererbung verwendet werden, obwohl ich argumentieren kann, dass eine Klasse aufgrund ihrer Abstraktion umso schwieriger zu lesen ist, je mehr Vererbung wir haben.

Weitere Informationen zur klassenbasierten Ansicht in Django-Dokumenten finden Sie hier, hier, hier

Auch ein gutes alternatives Dokument, das sich auf die auf Django-Klassen basierende Ansicht konzentriert, ist ccbv.co.uk