Guide pour l'organisation de grands projets Django

Question

Quelqu'un pourrait-il recommander un bon guide/tutoriel/article avec des astuces/guides sur la façon d'organiser et de partitionner un gros projet Django ?

Je cherche des conseils sur ce qu'il faut faire quand on doit commencer à factoriser les fichiers uniques initiaux (models.py, urls.py, views.py) et travailler avec plus de quelques dizaines d'entités.

Answer 1

Chaque "application" doit être petite - une seule entité réutilisable et quelques tables associées. Nous avons environ 5 plus ou moins 2 tables par modèle d'application. La plupart de notre demi-douzaine d'applications sont plus petites que 5 tables. L'une d'entre elles n'a aucune table dans son modèle.

Chaque application doit être conçue pour être un concept réutilisable. Dans notre cas, chaque application est un élément du site global ; les applications peuvent être retirées et remplacées séparément.

En effet, c'est notre stratégie. Au fur et à mesure que nos besoins se développent et mûrissent, nous pouvons supprimer et remplacer les applications indépendamment les unes des autres.

Il est acceptable que les applications dépendent les unes des autres. Cependant, la dépendance doit être limitée aux éléments évidents comme les "modèles" et les "formulaires". En outre, les applications peuvent dépendre des noms figurant dans les URL des autres applications. Par conséquent, vos URL nommées doivent avoir une forme telle que "application-view", de sorte que la balise reverse ou la fonction {% url %} l'étiquette peut les trouver correctement.

Chaque application doit contenir ses propres commandes batch (généralement via une commande formelle qui peut être trouvée par la commande django-admin script.

Enfin, tout ce qui est plus complexe qu'un simple modèle ou formulaire partagé n'appartient probablement pas à l'une ou l'autre des applications, mais doit faire l'objet d'une bibliothèque partagée distincte. Par exemple, nous utilisons XLRD mais en enveloppant certaines parties dans notre propre classe pour qu'elle ressemble davantage à la classe intégrée de l'entreprise. csv module. Ce wrapper pour XLRD ne fait pas partie intégrante d'une application, c'est un module séparé, en dehors des applications Django.

Answer 2

J'ai constaté qu'il est utile de jeter un coup d'œil aux grands projets Django à code source ouvert et de prendre note de la façon dont ils procèdent. Le site de Django propose une bonne liste de projets open-source :

http://code.djangoproject.com/wiki/DjangoResources#Open-SourceDjangoprojects

Tout comme Google (bien que la plupart d'entre eux soient des balises de modèles d'extension plus petites et des intergiciels :

http://code.google.com/hosting/search?q=label:django

Bien sûr, ce n'est pas parce qu'un projet procède d'une certaine manière que cette manière est la bonne (ou la mauvaise). Certains de ces projets sont plus réussis que d'autres.

En fin de compte, la seule façon d'apprendre réellement ce qui fonctionne et ce qui ne fonctionne pas est d'essayer soi-même. Tous les conseils et astuces du monde ne seront d'aucune utilité si vous n'essayez pas vous-même, mais ils peuvent vous aider à prendre la bonne direction.