Heim  >  Artikel  >  Backend-Entwicklung  >  Django-Studiennotizen – Klassenbasierte Ansicht

Django-Studiennotizen – Klassenbasierte Ansicht

高洛峰
高洛峰Original
2017-02-18 10:17:291225Durchsuche

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:

  1. Verbessert die Wiederverwendbarkeit von Code und Sie können objektorientierte Technologie wie Mixin (Mehrfachvererbung) verwenden

  2. 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(&#39;result&#39;)

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(&#39;result&#39;)

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

In die URL schreiben Sie einfach:

# urls.py
from django.conf.urls import url
from myapp.views import MyView
 
urlpatterns = [
 url(r&#39;^about/$&#39;, MyView.as_view()),
]

Die Attribute der Klasse können auf zwei Arten festgelegt werden, die erste ist üblich Python-Methoden können von Unterklassen überschrieben werden.

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"

Zweite Methode, Sie können die Attribute der Klasse auch in der URL angeben:

Legen Sie die Attribute der Klasse fest die URL Python

urlpatterns = [
 url(r&#39;^about/$&#39;, GreetingView.as_view(greeting="G&#39;day")),
]

Mixin verwenden

Ich denke du Sie müssen die klassenbasierte Ansicht von Django (im Folgenden als CBV bezeichnet) verstehen. Sie müssen zunächst den Zweck der Einführung von CBV in Django verstehen. Vor Django 1.3 war die generische Ansicht die sogenannte universelle Ansicht, die die funktionsbasierte Ansicht (fbv) verwendete, eine funktionsbasierte Ansicht. Manche Leute denken, dass fbv pythonischer ist als cbv, aber sie denken anders. Eines der wichtigen Merkmale von Python ist die Objektorientierung. Und cbv kann die objektorientierte Natur von Python besser widerspiegeln. cbv implementiert Ansichtsmethoden über Klassen. Im Vergleich zur Funktion können Klassen die Spezifität des Polymorphismus besser nutzen, sodass es einfacher ist, die häufigeren Funktionen innerhalb des Projekts von der Makroebene aus zu abstrahieren. Bezüglich Polymorphismus gibt es nicht viele Erklärungen. Interessierte Schüler können es selbst googeln. Kurz gesagt, es kann als eine Sache mit mehreren Formen (Eigenschaften) verstanden werden. Das Implementierungsprinzip von cbv kann leicht verstanden werden, indem man sich den Quellcode von django ansieht. Im Allgemeinen wird die URL nach der Weiterleitung an diesen cbv über die Dispatch-Methode innerhalb von cbv verteilt und die Get-Anfrage an cbv.get verteilt Methode zur Verarbeitung, und die Post-Anfrage wird an cbv verteilt. Post-Methode verarbeitet, andere Methoden sind ähnlich. Wie nutzt man Polymorphismus? Das Konzept des Mixin wurde in CBV eingeführt. Bei Mixin handelt es sich lediglich um einige Grundklassen, die geschrieben und dann mit verschiedenen Mixins kombiniert wurden, um die endgültige gewünschte Klasse zu ergeben.


Die Grundlage für das Verständnis von CBV ist also das Verständnis von Mixin. Mixins werden in Django verwendet, um Code wiederzuverwenden. Eine View-Klasse kann mehrere Mixins erben, sie kann jedoch nur eine View (einschließlich Unterklassen von View) erben. Es wird empfohlen, View ganz rechts und mehrere Mixins links zu schreiben. Mixin ist auch eine relativ komplexe Technologie. Ich werde in diesem Artikel nicht näher darauf eingehen, sondern einen Artikel über Mixin schreiben.

Dekoratoren verwenden

In CBV können Sie method_decorator verwenden, um Methoden zu dekorieren.

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 = &#39;secret.html&#39;
 
 @method_decorator(login_required)
 def dispatch(self, *args, **kwargs):
  return super(ProtectedView, self).dispatch(*args, **kwargs)

kann auch in die Klasse geschrieben und im Namen der Methode übergeben werden.

@method_decorator(login_required, name=&#39;dispatch&#39;)
class ProtectedView(TemplateView):
 template_name = &#39;secret.html&#39;

Wenn es mehrere Dekorateure gibt, die eine Methode dekorieren, können diese als Liste geschrieben werden. Beispielsweise sind die folgenden beiden Schreibweisen gleichwertig.

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=&#39;dispatch&#39;)
class ProtectedView(TemplateView):
 template_name = &#39;secret.html&#39;


Weitere Artikel zur klassenbasierten Ansicht in Django-Studiennotizen finden Sie unter PHP chinesische Website!


Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn