web-dev-qa-db-fra.com

Django: "projets" vs "applications"

J'ai un "produit" assez complexe, je suis prêt à construire avec Django. Je vais éviter d'utiliser les termes "projet" et "application" dans ce contexte, car je ne comprends pas bien leur signification dans Django.

Les projets peuvent avoir de nombreuses applications. Les applications peuvent être partagées entre plusieurs projets. Bien.

Je ne réinvente pas le blog ou le forum - aucune partie de mon produit ne peut être réutilisée dans aucun contexte. Intuitivement, j'appellerais celui-ci "application". Est-ce que je fais ensuite tout mon travail dans un seul dossier "app"?

Si oui ... en termes de project.app espace de noms, mon inclination est d’utiliser myproduct.myproduct, mais bien sûr cela n'est pas autorisé (mais l'application que je construis est mon projet et mon projet est une application!). Je suis donc amené à croire que je suis peut-être censé approcher Django en construisant une application par modèle "significatif", mais je ne sais pas où tracer les limites de mon schéma séparez-le en applications - j'ai beaucoup de modèles avec des relations relativement complexes.

J'espère qu'il y a une solution commune à cela ...

pythondjangonamespacesproject-organization
193
Dolph

Qu'est-ce qui vous empêche d'utiliser myproduct.myproduct? Ce que vous devez faire pour y parvenir consiste en gros à faire ceci:

Django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

etc. Cela aiderait-il si je disais que views.py Ne doit pas s'appeler views.py? Si vous pouvez nommer, sur le python), une fonction (généralement package.package.views.nom_fonction), elle sera gérée. Aussi simple que cela. Tout ce "projet"/"application" est juste python paquets.

Maintenant, comment es-tu censé le faire? Ou plutôt, comment pourrais-je le faire? Eh bien, si vous créez un élément important de fonctionnalités réutilisables, comme par exemple un éditeur de balisage, vous créez alors une "application de niveau supérieur" pouvant contenir widgets.py, fields.py, context_processors.py etc. - toutes les choses que vous pouvez importer.

De même, si vous pouvez créer quelque chose comme un blog dans un format assez générique pour toutes les installations, vous pouvez l'envelopper dans une application, avec son propre modèle, son dossier de contenu statique, etc., et configurer une instance d'un Django projet d'utiliser le contenu de cette application.

Il n'y a pas de règles strictes stipulant que vous devez le faire, mais c'est l'un des objectifs du cadre. Le fait que tout, modèles inclus, vous permette d'inclure à partir d'une base commune signifie que votre blog doit s'intégrer parfaitement à toute autre configuration, simplement en prenant soin de sa propre partie.

Cependant, pour répondre à votre préoccupation réelle, oui, rien ne dit que vous ne pouvez pas travailler avec le dossier de projet de niveau supérieur. C'est ce que font les applications et vous pouvez le faire si vous le souhaitez vraiment. J'ai tendance à ne pas, cependant, pour plusieurs raisons:

  • La configuration par défaut de Django ne le fait pas.
  • Souvent, je veux créer une application principale, alors j'en crée une, généralement appelée website. Cependant, il se peut que je veuille développer ultérieurement des fonctionnalités originales uniquement pour ce site. En vue de le rendre amovible (que je le fasse ou non), j'ai tendance à créer ensuite un répertoire séparé. Cela signifie également que je peux supprimer cette fonctionnalité simplement en dissociant ce paquet de la configuration et en supprimant le dossier, plutôt qu’un complexe, supprimer les bonnes URL du dossier global urls.py.
  • Très souvent, même lorsque je veux faire quelque chose d'indépendant, il a besoin d'un endroit pour vivre pendant que je m'en occupe/le rend indépendant. Fondamentalement, le cas ci-dessus, mais pour des choses que j'ai l'intention de faire générique.
  • Mon dossier de niveau supérieur contient souvent quelques autres éléments, y compris, sans toutefois s'y limiter, les scripts wsgi, les scripts SQL, etc.
  • Django's extensions de gestion s'appuie sur des sous-répertoires. Il est donc logique de nommer les paquets de manière appropriée.

En bref, la raison pour laquelle il existe une convention est la même que toute autre convention - cela aide les autres personnes travaillant avec votre projet. Si je vois fields.py, J'attends immédiatement du code dans la sous-classe du champ de Django, alors que si je voyais inputtypes.py, Je ne serais peut-être pas aussi clair sur ce que cela signifie sans le regarder.

56
user257111

Une fois que vous avez fini d'utiliser startproject et startapp, rien ne vous empêche de combiner un "projet" et une "application" dans le même Python. A projet n'est en réalité qu'un module settings, et une application n'est en réalité qu'un module models: tout le reste est facultatif.

Pour les petits sites, il est tout à fait raisonnable d'avoir quelque chose comme:

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py
89
claymation

Essayez de répondre à la question: "Que fait mon application?". Si vous ne pouvez pas répondre en une seule phrase, vous pourrez peut-être la diviser en plusieurs applications avec une logique plus claire.

J'ai lu cette pensée quelque part peu de temps après avoir commencé à travailler avec Django et je constate que je me pose souvent cette question et que cela m'aide beaucoup.

Vos applications ne doivent pas nécessairement être réutilisables, elles peuvent dépendre les unes des autres, mais elles doivent faire une chose.

69
Ski

J'ai trouvé les articles de blog suivants très utiles sur les applications et projets Django:

En principe, vous avez beaucoup de liberté avec Django) pour organiser le code source de votre produit.

15
JooMing

Si c'est le cas ... en termes d'espace de noms project.app de Django, mon inclination est de usemyproduct.myproduct, mais bien sûr cela n'est pas autorisé

Il n'y a rien comme interdit. C'est votre projet, personne ne vous limite. Il est conseillé de garder un nom raisonnable.

Je ne vois aucune partie de mon produit réutilisable dans aucun contexte. Intuitivement, j'appellerais celui-ci "application". Est-ce que je fais ensuite tout mon travail dans un seul dossier "app"?

Dans un projet général Django, il existe de nombreuses applications (applications contrib)) qui sont réellement utilisées dans chaque projet.

Disons que votre projet ne fait qu'une tâche et n'a qu'une seule application (je l'appelle main car le projet tourne autour d'elle et est à peine connectable). Ce projet utilise aussi toujours d’autres applications.

Maintenant, si vous dites que votre projet utilise uniquement une application (INSTALLED_APPS='myproduct') alors quelle est l’utilisation de project pour définir le projet comme project.app, Je pense que vous devriez considérer certains points:

  • Le code autre que l’application dans un projet traite de nombreux autres éléments (fichiers statiques de base, modèles de base, paramètres, etc., c’est-à-dire la base).
  • Dans l’approche générale project.app Django définit automatiquement le schéma SQL à partir de modèles.
  • Votre projet serait beaucoup plus facile à construire avec l'approche conventionnelle.
  • Vous pouvez définir des noms différents pour les URL, les vues et d’autres fichiers à votre guise, mais je ne vois pas la nécessité.
  • Il se peut que vous deviez ajouter des applications à l’avenir, ce qui serait très facile avec les projets classiques Django) qui, autrement, pourraient devenir tout aussi difficiles, voire plus fastidieux.

En ce qui concerne l'essentiel du travail effectué dans l'application, je pense que c'est le cas de la plupart des Django projets.

8
crodjer

Ici Django les créateurs signalent cette différence eux-mêmes . Je pense que penser aux applications, car elles doivent être réutilisables dans d’autres projets, est bien . C'est également un bon moyen de penser aux applications dans Django pour fournir des applications Web modernes.

Imaginez que vous créez une application Web dynamique dynamique basée sur (== --- ==) JavaScript .

Vous pouvez ensuite créer dans Django App nommée par exemple "FrontEnd" <- dans cette application, vous pourrez afficher le contenu.

Ensuite, vous créez des applications d'arrière-plan. E.g App nommée "Commentaires" qui stockera les commentaires de l'utilisateur. Et "Commentaires" App ne affichera rien lui-même. Ce sera juste une API pour AJAX demandes de votre dynamique [~ # ~] js [~ # ~] site Web .

De cette façon, vous pouvez toujours réutiliser votre application "Commentaires". Vous pouvez le rendre open source sans ouvrir la source de tout le projet. Et vous gardez une logique propre de votre projet.

1
Qback