Est-ce que j'ai organisé mon application django correctement?

Question

Je suis dans une situation où j'ai besoin de fusionner deux applications Django en une application unique et réutilisable. Aucun d'entre eux n'est particulièrement important, mais ils ne sont certainement pas des applications triviales et pour préserver la lisibilité/la santé mentale, j'essaie de garder les deux applications séparées dans une certaine mesure.

Je pourrais configurer chaque application comme un sous-package (ce qui serait un moyen pythonique d'y parvenir), ou je peux m'en tenir aux conventions de Django et séparer les fonctionnalités séparément dans chaque cas.

A 'sous-package' Pythonic approche:

package 
|-- __init__.py 
|-- views.py 
|-- models.py  # imports models from both sub-packages 
|-- tests.py  # imports TestCase instances from both sub-packages 
|-- etc.   # shared stuff 
|-- a 
| |-- __init__.py 
| |-- views.py 
| |-- models.py 
| |-- tests.py 
| `-- etc.  # a-specific code 
`-- b 
    |-- __init__.py 
    |-- views.py 
    |-- models.py 
    |-- tests.py 
    `-- etc.  # b-specific code 

Ou pour apaiser les dieux Django plus directement:

package 
|-- __init__.py 
|-- views 
| |-- __init__.py 
| |-- a.py 
| `-- b.py 
|-- models 
| |-- __init__.py # imports models from a and b 
| |-- a.py 
| `-- b.py 
|-- tests 
| |-- __init__.py # imports TestCase instances from a and b 
| |-- a.py 
| `-- b.py 
`-- etc. # shared/additional files 

Alors que je penche vers l'ancien au moment (qui se sent un peu plus léger), mon instinct me dit que bien que les deux fonctionnent (et les deux impliquent d'importer des 'hacks' pour se conformer à la structure de Django) le meilleur choix dépend du contenu de a et b - spécifiquement quelle part du code est partagée ou appliquée spécifique. Il ne convient pas de répéter constamment le modèle __ init__.py, a.py, b.py dans chaque sous-répertoire!

Je suis curieux de savoir lequel serait le plus approprié de la part des personnes ayant plus d'expérience avec Python!

ps. Je suis conscient qu'ils pourraient vivre comme deux applications distinctes, mais ils sont tellement interdépendants maintenant que je me sens comme ils devraient être fusionnés! (même en dehors de la portabilité améliorée d'une seule application Django)

Answer 1

L'état plat est meilleur que l'imbriqué.

Une application "composite", construite à partir de deux applications homologues est très bien. Ça marche bien.

Et il favorise la réutilisation en permettant aux deux composants d'être des options «plug-and-play» dans l'application plus grande. Ne pas imbriquer des choses sauf si vous y êtes obligé. La raison numéro un forçant vous imbriquer est les collisions de nom. Vous n'avez pas cela, donc vous n'avez pas vraiment besoin d'imbrication.

Answer 2

Je ne suis pas un expert en python mais j'aime toujours séparer les applications et autres artefacts autant que possible.

Je suis l'approche qui est décrite dans ce blog pour mon propre projet django et cela nécessite un peu de peaufinage sur django. Cela m'a bien servi jusqu'à présent.

Le lien direct vers le github project

Answer 3

Dans mes projets, je veux souvent d'organiser des points de vue et des tests d'une certaine manière, donc j'utiliser la structure comme ceci:

package 
|-- __init__.py 
|-- models.py  # models are in one file 
|-- etc.   # shared stuff 
|-- tests 
| |-- __init__.py 
| |-- tests_orders.py 
| |-- tests_clients.py 
| |-- 
| `-- etc. 
|-- views 
| |-- __init__.py 
| |-- orders.py 
| |-- clients.py 
| |-- 
| `-- etc. 

Pour les grands projets ayant une fonction d'affichage dans un fichier est une douleur (pour moi).

C'est ce qui fonctionne pour certains projets sur lesquels je travaille - j'espère que quelqu'un trouvera cela utile aussi.