Vorwort
Jeder weiß, dass das Erlernen von Django eigentlich sehr einfach ist und man fast ohne Aufwand damit beginnen kann. Es ist fast nichts schwer zu verstehen, eine URL zu konfigurieren, sie einer Funktion zuzuordnen, um sie zu verarbeiten, und eine Antwort zurückzugeben.
Je mehr ich schreibe, desto klarer werden mir einige der Probleme. Beispielsweise ist eine Ansicht relativ komplex und ruft viele andere Funktionen auf. Was soll ich tun, wenn ich diese Funktionen kapseln möchte? Natürlich können Sie den Kommentar #------view------ verwenden, um die Funktion zu isolieren. Diese Methode ist zu niedrig, sie täuscht Sie einfach selbst und ist nicht einmal gekapselt.
Python ist eine objektorientierte Programmiersprache. Wenn Sie zum Entwickeln nur Funktionen verwenden, werden viele objektorientierte Vorteile verpasst (Vererbung, Kapselung, Polymorphismus). Deshalb fügte Django später die klassenbasierte Ansicht hinzu. Es ermöglicht uns, View mithilfe von Klassen zu schreiben. Dies hat vor allem die folgenden zwei Vorteile:
Verbessert die Wiederverwendbarkeit von Code und Sie können objektorientierte Technologie wie Mixin (Mehrfachvererbung) verwenden
Sie können verschiedene Funktionen verwenden, um verschiedene HTTP-Methoden zu verarbeiten, anstatt viele if-Urteile zu verwenden, um die Lesbarkeit des Codes zu verbessern
Verwenden Sie Klassen- basierte Ansichten
Wenn wir eine Ansicht schreiben möchten, die die GET-Methode verarbeitet, würde sie wie folgt aussehen, wenn sie mit einer Funktion geschrieben wird.
from django.http import HttpResponse def my_view(request): if request.method == 'GET': # <view logic> return HttpResponse('result')
Wenn es in der klassenbasierten Ansicht geschrieben würde, würde es so aussehen.
from django.http import HttpResponse from django.views import View class MyView(View): def get(self, request): # <view logic> return HttpResponse('result')
Djangos URL weist eine Anfrage einer aufrufbaren Funktion zu, nicht einer Klasse. Um dieses Problem zu lösen, stellt die klassenbasierte Ansicht eine statische Methode as_view()
bereit (d. h. durch Aufrufen dieser Methode wird eine Instanz der Klasse erstellt und dann die Methode dispatch()
aufgerufen). >-Methode wird basierend auf der Anfrage aufgerufen. Verschiedene Methoden rufen die entsprechende Methode auf, um die Anfrage zu bearbeiten (z. B. dispatch()
, get()
usw.). Zu diesem Zeitpunkt sind diese Methoden fast identisch mit funktionsbasierten Ansichten. Sie müssen Anfragen empfangen und eine Antwort zurückerhalten. Wenn die Methode nicht definiert ist, wird eine HttpResponseNotAllowed-Ausnahme ausgelöst. post()
# urls.py from django.conf.urls import url from myapp.views import MyView urlpatterns = [ url(r'^about/$', MyView.as_view()), ]
from django.http import HttpResponse from django.views import View class GreetingView(View): greeting = "Good Day" def get(self, request): return HttpResponse(self.greeting) # You can override that in a subclass class MorningGreetingView(GreetingView): greeting = "Morning to ya"
urlpatterns = [ url(r'^about/$', GreetingView.as_view(greeting="G'day")), ]
Mixin verwenden
Dekoratoren verwenden
from django.contrib.auth.decorators import login_required from django.utils.decorators import method_decorator from django.views.generic import TemplateView class ProtectedView(TemplateView): template_name = 'secret.html' @method_decorator(login_required) def dispatch(self, *args, **kwargs): return super(ProtectedView, self).dispatch(*args, **kwargs)
@method_decorator(login_required, name='dispatch') class ProtectedView(TemplateView): template_name = 'secret.html'
decorators = [never_cache, login_required] @method_decorator(decorators, name='dispatch') class ProtectedView(TemplateView): template_name = 'secret.html' @method_decorator(never_cache, name='dispatch') @method_decorator(login_required, name='dispatch') class ProtectedView(TemplateView): template_name = 'secret.html'