Conception de projet / mise en page FS pour les grands projets Django [fermé]

Question

Quelle est la meilleure façon de mettre en page un grand projet Django ?Les didacticiels fournissent des instructions simples pour configurer des applications, des modèles et des vues, mais il y a moins d'informations sur la façon dont les applications et les projets doivent être décomposés, sur le degré de partage autorisé/nécessaire entre les applications dans un projet typique (cela dépend évidemment en grande partie de le projet) et comment/où les modèles généraux doivent être conservés.

Quelqu'un a-t-il des exemples, des suggestions et explications Pourquoi une certaine configuration de projet est meilleure qu'une autre ?Je suis particulièrement intéressé par l'incorporation d'un grand nombre de tests unitaires (2 à 5 fois la taille de la base de code réelle) et par l'externalisation/modèles de chaînes.

Answer 1

Les principales directives sont similaires à celles de tout autre grand projet de code.Les applications doivent répondre à une responsabilité unique et clairement définie.Le nom « application » est un abus de langage ;Les applications Django doivent être davantage considérées comme des composants réutilisables qui peuvent être connectés ensemble pour créer une véritable application.Les tests pour chaque application doivent être contenus dans cette application.Les applications doivent être découplées les unes des autres autant que possible, mais il y aura clairement des dépendances, l'objectif devrait donc être de garder le graphique des dépendances aussi simple et sain que possible.

Je préfère conserver tous les modèles d'un projet dans un seul répertoire de modèles à l'échelle du projet, avec un sous-répertoire pour chaque application (l'utilisation d'un sous-répertoire de modèles pour chaque application est une convention très forte dans Django, car elle évite les collisions de noms de modèles entre applications) .La raison pour laquelle il existe un répertoire de modèles unique à l'échelle du projet est que les modèles, les arborescences d'héritage de modèles et les noms de blocs peuvent être assez spécifiques au projet. Il est donc difficile de fournir des modèles d'application « par défaut » pouvant se connecter à n'importe quel projet.Il y a eu quelques tentatives pour définir des conventions de dénomination standard pour les modèles de base à l'échelle du site et les blocs qu'ils définissent, mais je n'ai pas encore vu de norme émerger (la façon dont ils font les choses chez Pinax est probablement ce qui se rapproche le plus d'une norme).

Concernant "l'externalisation de chaînes", si vous voulez dire i18n et l10n, Django prend fortement en charge cela et les emplacements standard où il place les fichiers .po - vérifiez le documents.

Answer 2

J'ai trouvé la mise en page de Zachary très utileBlog de Zachary Voase »Les conventions du projet Django, revisitées.

Answer 3

Cette page répond bien à certaines de mes questions : http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Spécifiquement:

1. Pour définir des balises ou des filtres de modèle personnalisés, vous devez créer un sous-répertoire dans le répertoire de l'application appelé templatetags, et il doit contenir un fichier nommé __init__.py afin qu'il puisse être importé en tant que module Python.
2. Pour définir des tests unitaires qui seront automatiquement remarqués par le framework de test de Django, placez-les dans un module appelé tests (qui peut être soit un fichier nommé tests.py, soit un répertoire appelé tests).Le framework de test trouvera également tous les doctests dans ce module, mais l'endroit préféré pour ceux-ci est, bien sûr, les docstrings des classes ou des fonctions qu'ils sont conçus pour tester.
3. Pour fournir du SQL personnalisé qui sera exécuté immédiatement après l'installation de votre application, créez un sous-répertoire appelé sql dans le répertoire de l'application ;les noms de fichiers doivent être les mêmes que les noms des modèles sur lesquels ils opèreront ;par exemple, si vous avez une application nommée weblog contenant un modèle nommé Entry, alors le fichier sql/entry.sql dans le répertoire de l'application peut être utilisé pour modifier ou insérer des données dans la table des entrées dès sa création.

La note sur tests.py et tests (le répertoire) s'applique également aux modèles, ce qui permet de résoudre le problème de l'accès à plusieurs tests (ou modèles) pour un seul fichier.

J'aimerais toujours voir quelques exemples/suggestions de décomposition d'applications/projets et de gros sites Django qui fonctionnent bien.

Answer 4

Le Projet Pinax est construit autour de l'idée de petites applications réutilisables, qui sont facilement regroupées dans un projet.Ils ont utilisé le projet Nuage 27 comme projet de démonstration.

Le projet Django sur lequel je travaille (appelé Basie.C'est une version antérieure à la version 0.1, donc pas encore de lien.) essaie de suivre le modèle Pinax, et jusqu'à présent, cela fonctionne assez bien.

Answer 5

Ma mise en page actuelle vient du fait que je souhaite disposer d'une version test de mes sites.Cela signifie avoir deux projets pour chaque site, car ils nécessitent des configurations différentes, et m'oblige à déplacer toutes les applications hors des projets.

J'ai créé deux dossiers :$APP_ROOT/devel et $APP_ROOT/prod.Ceux-ci contiennent toutes les applications.En utilisant le contrôle de source (dans mon cas, git), j'ai les applications en développement à la révision HEAD, tandis que les applications en prod sont verrouillées sur la balise PROD.Les modèles ont également leur propre dossier avec la même présentation que les applications.

Je peux désormais effectuer tout mon développement dans le dossier devel-apps et le dossier de modèles correspondant.Quand j'ai quelque chose qui me satisfait, je marque cette révision et cette mise à jour.

Answer 6

J'aime vraiment Randall Degges post sur ce sujet.Il laisse de côté des informations sur la façon de coller les fichiers de paramètres ensemble, mais j'aurai un article sur lequel je pourrai créer un lien, mais pour l'instant, tout le monde peut le consulter. mon dépôt où j'inclus des instructions dans le fichier readme.