Comment gérez-vous vos applications Django?

Question

Je voulais juste essayer de construire un projet avec django. Par conséquent, j'ai une question (de base) sur la façon de gérer un tel projet. Comme je ne trouve pas de lignes directrices ou comment diviser un projet en applications.

Prenons une sorte de SO comme exemple. Quelles applications utiliseriez-vous? Je dirais qu'il devrait y avoir les applications "users" et "questions". Mais que se passerait-il s'il y avait un système de sujets avec des articles statiques, aussi. Peut-être qu'ils pourraient aussi recevoir des votes. Comment construire la structure des applications alors? Une application pour "questions", "votes" et "sujets" ou juste une application "contenu"?

Je n'ai aucune idée de quoi faire. Peut-être que c'est parce que je ne sais pas encore beaucoup sur Django, mais ça m'intéresse non plus ...

Answer 1

Je vais vous dire comment j'aborde une telle question: je m'assois habituellement avec une feuille de papier et je dessine les boîtes (fonctionnalités) et flèches (interdépendances entre fonctionnalités). Je suis sûr qu'il existe des méthodologies ou d'autres choses qui pourraient vous aider, mais mon approche fonctionne généralement pour moi (YMMV, bien sûr). Savoir ce qu'un site est censé être est fondamental, cependant. ;)

Answer 2

Vous devriez essayer de séparer le projet dans autant d'applications que possible. Pour la plupart des projets, une application ne contiendra pas plus de 5 modèles. Par exemple un projet comme SO aurait des applications séparées pour UsersProfiles, Questions, Tags (il y en a un en django), etc. S'il y avait un système avec des pages statiques qui seraient aussi une application séparée (il y en a dans ce but). Vous devriez également essayer de rendre vos applications aussi génériques que possible, afin de pouvoir les réutiliser dans d'autres projets. Il y a un bon presentation sur les applications réutilisables.

Answer 3

Tout comme n'importe quel ensemble de dépendances ... essayez de trouver les aspects autonomes les plus utiles du projet et de créer ces applications autonomes. Les autres applications Django auront des fonctionnalités de niveau supérieur et réutiliseront les parties des applications de niveau inférieur que vous avez configurées.

Dans mon projet, j'ai une application de calendrier avec son propre objet Event dans ses modèles. J'ai aussi une base de données de covoiturage mise en place, et pour l'heure de départ et la durée, j'utilise l'objet événement du calendrier directement dans mes tables RideShare. La base de données de covoiturage est sensible au calendrier, et obtient toutes les belles vues d'exportation et de calendrier .ics de l'application de calendrier pour «libre».

Il existe quelques astuces pour réutiliser les applications, comme nommer le répertoire des modèles: project/app2/templates/app2/index.html. Cela vous permet de vous référer à app2/index.html de n'importe quelle autre application, et d'obtenir le bon modèle. J'ai choisi celui-là en regardant les applications réutilisables intégrées dans Django lui-même. Pinax est un peu un monstre de taille, mais il montre aussi une belle structure d'application réutilisable.

En cas de doute, oubliez les applications réutilisables pour le moment. Mettez tous vos messages et sondages dans une application et passer à travers un rev. Vous découvrirez au cours du processus quelles sont les étapes qui ne vous sembleront pas nécessaires et qui pourraient être considérées comme autonomes dans le futur.

Answer 4

Il n'y a pas de règles strictes, mais je dirais qu'il vaut mieux se tromper du côté des applications plus spécialisées. Idéalement, une application ne devrait traiter qu'une seule préoccupation fonctionnelle: c'est-à-dire "marquage" ou "commentaire" ou "auth/auth" ou "posts". Ce type de conception vous aidera également à réutiliser les applications open source disponibles au lieu de réinventer la roue (par exemple, Django est livré avec les applications auth et comments, django-tagging ou django-taggable peut certainement faire ce dont vous avez besoin, etc.).

Generic foreign keys peut vous aider à découpler les applications telles que le balisage ou les commentaires qui pourraient être appliqués aux modèles de plusieurs autres applications.

Answer 5

Une bonne question à vous poser lorsque vous décidez d'écrire ou non une application est "pourrais-je l'utiliser dans un autre projet?". Si vous pensez que vous pourriez, alors considérez ce qu'il faudrait pour rendre la demande aussi indépendante que possible; Comment pouvez-vous réduire les dépendances de sorte que l'application ne repose sur rien de spécifique à un projet particulier.

Certaines des façons dont vous pouvez le faire sont:

• Donner à chaque application sa propre urls.py
• Permettre les types de modèles à passer en tant que paramètres plutôt que de déclarer explicitement quels modèles sont utilisés dans votre vues. Les vues génériques utilisent ce principe. Faites en sorte que vos modèles soient facilement remplacés par une sorte de paramètre template_name passé dans votre urls.py
• Assurez-vous que vous pouvez effectuer des recherches inversées d'URL avec vos objets et vos vues. Cela signifie nommer vos vues dans urls.py et créer des méthodes get_absolute_url sur vos modèles. GenericForeignKeys peut parfois être utilisé pour associer un modèle dans votre application à n'importe quel autre modèle, que ForeignKeys y "regarde en arrière".