Django, en tant que framework d'application Web puissant, est progressivement devenu populaire ces dernières années. De plus en plus de développeurs Python investissent dans Django, mais aussi en raison des nombreux problèmes de Django Content, alors que tout le monde. Quand ils entrent pour la première fois dans Django, ils se sentent toujours un peu "un peu dépassés" et ne savent pas par où commencer. Ou encore, après une première compréhension, vous ne savez toujours pas si l'approche actuelle est élégante, comment organiser le projet et comment rendre le code plus réutilisable.
Une bonne structure de projet représente la moitié de la bataille.
Par défaut, la structure du projet générée par Django ressemble à ceci :
À mesure que le nombre d'applications dans le projet continue d'augmenter, les packages dans le répertoire racine local continueront d'augmenter À mesure que le nombre de fichiers augmente, il devient de plus en plus difficile à maintenir, nous devons donc avoir un plan clair pour l'ensemble du projet et placer raisonnablement chaque fichier.
Si le projet est petit et que vous ne prévoyez pas de réutiliser l'application de diverses manières, vous pouvez envisager les méthodes suivantes :
Le dossier venv stocke l'environnement virtualenv du projet. Ce n'est pas nécessaire et peut. être placé ailleurs.
L'application Database est spécialement utilisée pour stocker le modèle, gérer les commandes et certains filtres personnalisés utilisés dans les modèles. Elle est stockée dans le répertoire racine du projet.
docs et logs stockent respectivement les documents liés au projet et les fichiers journaux générés pendant l'exécution.
static stocke les fichiers statiques, tels que css/js/img/font, etc.
utils stocke les fonctions des outils, les classes utilisées dans le projet et certains modules courants, tels que l'enregistreur, etc.
templates stocke les fichiers de modèles. Le ou les modèles parents hérités de plusieurs modèles sont placés dans le répertoire racine et nommés avec des noms tels que base pour une maintenance facile. Les modèles restants sont placés dans des dossiers avec les noms d'application correspondants.
Le répertoire Web stocke toutes les applications. S'il existe de nombreuses applications, elles peuvent être divisées en plusieurs packages pour la planification. Chaque package stocke un type d'application.
Dans la partie module Modèle, nous nous intéressons principalement au mappage des données aux classes. Dans des circonstances normales, les classes correspondant à chaque table seront placées dans un fichier séparé, et les classes correspondantes seront placées. dans models/__init__.py Les classes sont importées dans l'ordre, de sorte que lorsqu'elles sont utilisées à d'autres endroits, elles puissent être importées via database.models import xxxx Lors du nom des classes, il est recommandé d'ajouter le nom du projet. Par exemple, le nom de mon projet ici est Cherry, alors toutes les classes sont CherryLeaks, etc., cela sera clair en un coup d'œil lors de la révision du code et du processus d'écriture, sachant que cette classe représente des données.
Il est recommandé d'ajouter un gestionnaire distinct pour les modèles et de mettre en œuvre les méthodes correspondantes pour éviter les opérations répétées.
De plus, il existe quelques suggestions, qui peuvent être choisies en fonction de la situation réelle :
Il n'est pas recommandé d'utiliser des types tels que des clés étrangères
Ajoutez les champs is_deleted,created_time et update_time à chaque table
Réparez utilisation des index
La plupart de la logique métier doit être placée dans la partie Vue, et cette partie doit être le noyau. Il est également recommandé ici de placer toutes les vues ayant des fonctions similaires dans le même fichier. Pour faciliter la maintenance et le développement futurs, ce fichier doit être placé dans un package nommé « contrôleur » ou « vue ». Par exemple, la gestion du routage lié au projet est entièrement placée dans controller/project.py.
Préférez utiliser certaines des classes View intégrées de Django, telles que ListView, TemplateView, etc. Si vous devez implémenter View vous-même, il est recommandé d'utiliser la vue basée sur les classes pour encapsuler différentes méthodes de requête dans différentes méthodes afin de faciliter la maintenance future. .
Pour les fichiers modèles, le meilleur moyen est de découper différentes pages et fonctions en différents fichiers modèles et de les stocker dans des dossiers sous le nom d'Application, afin qu'ils puissent être rapidement récupérés lors d'une maintenance ultérieure. fichier modèle correspondant.
De plus, il est fortement recommandé d'utiliser la fonction d'héritage de modèle. Toutes les pages sont héritées du modèle parent et divers blocs sont utilisés pour développer la page. Le nom de bloc de chaque position est défini dans le modèle parent pour les modèles enfants. couvrir. Il est recommandé d'utiliser un nom populaire et court pour chaque bloc, tel que : barre latérale, script, en-tête, main_content, page_title, page_description, etc.
Pour les fonctions courantes, telles que les zones de commentaires, vous pouvez envisager de les stocker dans un fichier séparé et de les charger via {% include 'filename.tpl.html' %} si nécessaire. Il convient de noter que si vous devez utiliser les extensions et inclure des instructions en même temps, vous devez les utiliser dans un bloc, sinon elles seront invalides. Les exemples suivants ne sont pas valides :
doit être utilisé comme suit :
La flexibilité du langage Python nous fait parfois oublier le type de paramètre ou le type de retour d'une méthode spécifique lors de l'écriture de code. Dans ce cas, nous devons utiliser docstring pour fournir des annotations d'informations claires pour chaque méthode afin que d'autres puissent la développer et la maintenir. Reportez-vous à ce lien, si vous utilisez PyCharm, vous pouvez écrire une docstring à complétion automatique.
Dans de nombreux cas, nos méthodes doivent renvoyer plusieurs valeurs à l'appelant, ou revenir au front-end via JSON. Si les données sont renvoyées de manière aléatoire, cela entraînera une confusion dans le développement et dans le processus. à la fin, nous ne saurons pas ce que la méthode renvoie.
Une meilleure approche consiste à se mettre d'accord sur le format de retour. Pour revenir à l'appelant, renvoyez simplement un tuple et écrivez la signification de chaque valeur dans la docstring. En plus de renvoyer des résultats, nous devons parfois renvoyer une erreur pour indiquer si un problème ou une exception s'est produit lors du traitement des données. En général, il existe plusieurs méthodes disponibles :
Lancer une exception via raise
Retourner via plusieurs valeurs de retour, telles que err, result = func()
Retourner via un attribut de la classe, tel que instance = Class( ) ; err = instance.error_message
Ces trois méthodes ont toutes des avantages et des inconvénients et doivent être sélectionnées en fonction de la situation réelle du projet. Quelle que soit la méthode utilisée, elle doit être cohérente tout au long du projet et ne le fait pas. mélangez-les autant que possible ;
Pour le JSON renvoyé au front end, il faut que ce soit un peu plus compliqué, au moins 2~3 champs doivent être renvoyés :
code est le code d'état renvoyé par cet appel, qui peut être convenu en fonction de la situation réelle. Le message est un message facile à comprendre du code d'état qui peut être utilisé par les développeurs pour déboguer et fournir des notifications aux utilisateurs. Les données sont les informations réelles renvoyées. Dans de nombreux cas, ce champ peut ne pas être nécessaire. Le format spécifique du champ doit également être à nouveau convenu en fonction de la situation réelle.
Un routage élégant et simple garantit la qualité du projet et réduit les coûts de maintenance.
Django dispose d'un système de routage et d'un algorithme de routage puissants qui peuvent répondre à divers besoins de l'entreprise, et la configuration est flexible et simple. Chaque fichier de configuration de routage est un mappage du CHEMIN d'URL à la fonction/classe. Tout peut être mis en place par vous-même, sans être soumis à des frameworks ou autres restrictions. Vous pouvez vous référer à cette section de la documentation sur les stratégies de routage des requêtes de Django.
Lors de la configuration des itinéraires, vous pouvez placer certaines variables entre crochets pour une utilisation facile plus tard. Certains "Convertisseurs de chemin" peuvent être utilisés entre crochets pour spécifier des types de variables, tels que str, int, slug, uuid, path. Un fichier de routage d'URL complet ressemble à ceci :
De plus, vous pouvez également définir une correspondance régulière dans la route via re_path :
Parfois, vous souhaiterez peut-être ajouter une route par défaut, par exemple, renvoie une page par défaut lors de l'accès à /blog/ et renvoie le contenu du numéro de page spécifié lors de l'accès à /blog/page
Comme le. Le projet continue de se développer, le nombre de routes utilisées continuera d'augmenter, c'est pourquoi Django fournit un mécanisme d'inclusion de routes pour nous faciliter l'organisation des routes dans différentes applications. Jetons un coup d'œil à un exemple simple :
Dans cet exemple, toutes les routes demandant community/* sont transmises à aggregator.urls pour analyse. De même, toutes les demandes de contact/* sont également transmises à un autre. un. Le module de routage le gère ; si vous n'avez pas autant d'applications dans votre projet et que vous souhaitez quand même gérer le routage via include, vous pouvez utiliser la méthode suivante :
Généralement, notre Each Le projet Django est composé de plusieurs applications. Si toutes les routes d'applications sont placées dans URLCONF_ROOT, ce fichier deviendra de plus en plus difficile à maintenir au fil du temps et sera très déroutant. Les itinéraires portant le même nom peuvent être utilisés dans différentes applications, provoquant des conflits. Afin de résoudre ces problèmes, nous pouvons utiliser « l'inclusion de route » et « l'espace de noms » pour le résoudre. Surtout si vous maintenez une application qui peut être réutilisée, afin de garantir l'unicité de la route, l'espace de noms est particulièrement important.
Il existe généralement deux types d'espaces de noms : l'espace de noms d'application et l'espace de noms d'instance. Par exemple, admin:index représente la route d'index de l'espace de noms d'administrateur. Pour plus d'informations sur cette partie, veuillez vous référer à : Documents officiels
L'espace de noms d'application est plus facile à comprendre. Il fait référence à l'espace de noms au niveau de l'application. Il est généralement organisé de la manière suivante :
L'espace de noms d'instance fait référence à l'espace de noms au niveau de l'instance, qui est souvent utilisé pour une application. être utilisé plusieurs fois. Dans le cas de l'instanciation, afin de distinguer chaque instance, l'espace de noms d'instance doit être introduit. Jetons un coup d'œil à l'exemple dans la documentation officielle :
Vous pouvez voir que les deux routes author-polls et editor-polls contiennent en fait la même route, mais spécifient des espaces de noms différents. Il s'agit de l'espace de dénomination au niveau de l'instance. , c'est-à-dire l'espace de noms de l'objet actuellement accédé. Différentes identités d'utilisateur obtiendront des espaces de noms différents lors de l'accès à différentes URL. Par exemple, les visiteurs et les administrateurs accéderont à la page pointée par polls:index, mais en raison des espaces de noms différents, ils obtiendront des résultats complètement différents.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
