Notes d'étude de Django - Vue basée sur les classes

Avant-propos

Tout le monde sait qu'apprendre Django est en fait très simple et que vous pouvez commencer avec presque aucun effort. Il n'y a presque rien de difficile à comprendre concernant la configuration d'une URL, son assignation à une fonction pour la traiter et le renvoi d'une réponse.

Plus j’écris, plus je réalise certains problèmes. Par exemple, une vue est relativement complexe et appelle de nombreuses autres fonctions. Que dois-je faire si je souhaite encapsuler ces fonctions ? Bien sûr, vous pouvez utiliser le commentaire #------view------ pour isoler la fonction. Cette méthode est tout simplement trompeuse. Elle n'est même pas encapsulée.

Python est un langage de programmation orienté objet. Si vous utilisez uniquement des fonctions pour développer, de nombreux avantages orientés objet seront manqués (héritage, encapsulation, polymorphisme). Django a donc ajouté plus tard Class-Based-View. Cela nous permet d'écrire View en utilisant des classes. Les avantages de ceci sont principalement les deux suivants :

1. Améliore la réutilisabilité du code et vous pouvez utiliser une technologie orientée objet, telle que Mixin (héritage multiple)

2. Vous pouvez utiliser différentes fonctions pour gérer différentes méthodes HTTP au lieu d'en utiliser plusieurs jugements if pour améliorer la lisibilité du code
   

utiliser la classe- vues basées

Si nous voulons écrire une vue qui gère la méthode GET, ce serait comme suit lorsqu'elle est écrite à l'aide d'une fonction.

from django.http import HttpResponse
 
def my_view(request):
 if request.method == 'GET':
  # <view logic>
  return HttpResponse(&#39;result&#39;)

S'il était écrit en vue basée sur les classes, cela ressemblerait à ceci.

from django.http import HttpResponse
from django.views import View
 
class MyView(View):
 def get(self, request):
  # <view logic>
  return HttpResponse(&#39;result&#39;)

L'URL de Django attribue une requête à une fonction appelable, pas à une classe. Pour résoudre ce problème, la vue basée sur les classes fournit une méthode statique as_view() (c'est-à-dire que l'appel de cette méthode créera une instance de la classe, puis appellera la méthode dispatch() via l'instance). > sera appelée en fonction de la requête. Différentes méthodes appellent la méthode correspondante pour gérer la requête (telle que dispatch(), get() , etc.). À ce stade, ces méthodes sont presque identiques aux vues basées sur les fonctions. Elles doivent recevoir des requêtes et obtenir une réponse. Si la méthode n'est pas définie, une exception HttpResponseNotAllowed sera levée. post()

Dans l'url, écrivez simplement :

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

Les attributs de la classe peuvent être définis de deux manières, la première est commune Les méthodes Python peuvent être remplacées par des sous-classes.

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"

Deuxième méthode, vous pouvez également spécifier les attributs de la classe dans l'url :

Définir les attributs de la classe dans l'url Python

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

Utilisation de Mixin

Je pense que tu Si vous devez comprendre la vue basée sur les classes de Django (ci-après dénommée cbv), vous devez d'abord comprendre le but de l'introduction de cbv dans Django. Avant Django 1.3, la vue générique était ce qu'on appelle la vue universelle, qui utilisait la vue basée sur les fonctions (fbv), qui est une vue basée sur les fonctions. Certaines personnes pensent que le fbv est plus pythonique que le cbv, mais ils pensent le contraire. L'une des fonctionnalités importantes de Python est l'orientation objet. Et cbv peut mieux refléter la nature orientée objet de python. cbv implémente les méthodes d'affichage via des classes. Par rapport à la fonction, la classe peut mieux utiliser la spécificité du polymorphisme, il est donc plus facile d'abstraire les fonctions les plus courantes au sein du projet à partir d'un niveau macro. Concernant le polymorphisme, il n’y a pas beaucoup d’explications. Les étudiants intéressés peuvent le rechercher eux-mêmes sur Google. En bref, cela peut être compris comme une chose ayant plusieurs formes (caractéristiques). Le principe d'implémentation de cbv est facile à comprendre en examinant le code source de Django. De manière générale, une fois l'URL acheminée vers ce cbv, elle est distribuée via la méthode de répartition à l'intérieur de cbv, la requête get est distribuée au cbv.get. méthode de traitement, et la demande de publication est distribuée au traitement de la méthode cbv .post, les autres méthodes sont similaires. Comment utiliser le polymorphisme ? Le concept de mixin est introduit dans cbv. Mixin ne sont que quelques classes de base qui ont été écrites, puis combinées avec différents Mixins pour devenir la classe finale souhaitée.

Donc, la base pour comprendre le cbv est de comprendre Mixin. Les mixins sont utilisés dans Django pour réutiliser le code. Une classe View peut hériter de plusieurs Mixins, mais elle ne peut hériter que d'une seule View (y compris les sous-classes de View). Il est recommandé d'écrire View à l'extrême droite et plusieurs Mixins à gauche. Mixin est également une technologie relativement complexe, je n'entrerai donc pas dans les détails dans cet article, j'écrirai un article sur Mixin dans le futur.

Utiliser des décorateurs

Dans CBV, vous pouvez utiliser method_decorator pour décorer des méthodes.

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)

peut également être écrit sur la classe et passer au nom de la méthode.

@method_decorator(login_required, name='dispatch')
class ProtectedView(TemplateView):
 template_name = 'secret.html'

S'il y a plusieurs décorateurs décorant une méthode, ils peuvent être écrits sous forme de liste. Par exemple, les deux manières d’écrire suivantes sont équivalentes.

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'

Pour plus d'articles liés à la vue basée sur les classes dans les notes d'étude de Django, veuillez prêter attention au Site Web chinois PHP !