Débutants. C'est une explication qu'une telle compréhension peut être bonne dans la pratique.
Dans Django, créez d'abord un modèle pour votre projet et votre application avec la commande suivante:
python
> django-admin startproject some_project
> cd some_project
> python manage.py startapp some_app
Ensuite, la structure du dossier est la suivante.
python
> tree /f some_project
C:\＊＊＊\SOME_PROJECT
│ manage.py
│
├─some_app
│ │ admin.py
│ │ apps.py
│ │ models.py
│ │ tests.py
│ │ views.py # <=Vue anticipée(Vue)Est une structure de fichier
│ │ __init__.py
│ │
│ └─migrations
│ __init__.py
│
└─some_project
│ settings.py
│ urls.py
│ wsgi.py
│ __init__.py
│
└─__pycache__
settings.cpython-37.pyc
__init__.cpython-37.pyc
Comme mentionné ci-dessus, la vue lors de la création d'une application se compose d'un fichier appelé views.py.
Si tu fais juste un essai, ça va comme ça, Dans le projet proprement dit, même si le démarrage prend un peu de temps Il vaut mieux donner la priorité à la facilité d'entretien.
La structure de View peut être modifiée en utilisant le mécanisme de Python. Je vais expliquer brièvement sous quel point vous pouvez penser de la configuration, y compris les recommandations.
Basée sur les classes est recommandée car vous souhaiterez peut-être utiliser la classe par défaut dans votre projet.
Il est difficile pour plusieurs personnes de gérer un fichier, il est donc recommandé de le conditionner.
Lors du packaging, il est recommandé d'importer avec \ _ \ _ init \ _ \ _. Py. Seule urls.py importe les vues, donc Ce n'est pas un must, mais du point de vue de l'appelant
python
from some_app.views.category.sub_category. import SomeView
que
python
from some_app.views import SomeView
Est plus doux car il ne vous informe pas de la composition sous l'emballage.
Je ne pense pas que l'un ou l'autre soit meilleur Je pense qu'il est bon de décider des règles.
Par exemple
Etc. Au moment de décider des règles, il est bon de prendre en compte les éléments suivants.
-Est-il facile d'imaginer et de rechercher le code source associé lorsque vous regardez l'écran? -N'est-ce pas gênant lors de l'édition avec un éditeur?
Cela peut être un peu extrême, mais nous recommandons ce qui suit:
** Écran de liste ** ListView (django.views.generic.ListView) ** Autre ** View (django.views.View)
ListView est recommandé car il peut utiliser la fonction de nation de page. Nous vous déconseillons d'utiliser d'autres vues génériques.
Il y a beaucoup de choses pour commencer, mais la simple raison est la suivante. ・ La lecture du code source prend du temps => ・ Les avantages n'en valent pas la peine => Ça devient compliqué ・ Ça devient difficile à déboguer
De plus, Django a Model (QuerySet) / Form. Certaines fonctionnalités utiles nécessitent des coûts d'apprentissage.
Plutôt que de comprendre la vue générique Il est certainement conseillé de leur consacrer des frais d'apprentissage.
Par exemple, CreateView (django.views.generic) a la relation d'héritage suivante.
c'est tout.