models.py devient énorme, quel est le meilleur moyen de le casser?

Question

Directions à partir de mon superviseur: "Je veux éviter de mettre de la logique dans l' models.py. À partir de maintenant, nous allons l'utiliser comme seules les classes pour l'accès à la base de données, et de garder toute logique dans les classes externes qui utilisent les modèles de classes, ou de la pellicule."

J'ai l'impression que c'est pas la voie à suivre. Je sens que le maintien de la logique des modèles juste pour garder le fichier de petite est une mauvaise idée. Si la logique est le meilleur dans le modèle, c'est là où il devrait vraiment aller indépendamment de la taille du fichier.

Donc, il y a un moyen simple d'utiliser le comprend? En PHP-parler, j'aimerais proposer au superviseur que nous venons models.py include() le modèle de classes à partir d'autres endroits. Sur le plan conceptuel, cela permettrait que les modèles ont tout de la logique que nous voulons, tout en gardant la taille du fichier via l'augmentation du nombre de fichiers (ce qui conduit à moins de contrôle de révision à des problèmes comme les conflits, etc.).

Alors, est-il un moyen simple de supprimer les classes du modèle de la models.py fichier, mais que les modèles de travail avec tous les Django d'outils? Ou, est-il un complètement différent, mais solution élégante à un problème général de "grand" models.py fichier? Toute entrée serait appréciée.

Answer 1

Il est naturel pour les classes de modèle pour contenir les méthodes de fonctionner sur le modèle. Si j'ai un Livre de référence, avec une méthode book.get_noun_count(), c'est là où il appartient--je ne veux pas à avoir à écrire "get_noun_count(book)", sauf si la méthode fait intrinsèquement appartient à un autre paquet. (Il peut, par exemple, si j'ai un colis pour accéder à Amazon de l'API avec "get_amazon_product_id(book)".)

Je grimaça lorsque Django documentation a suggéré de placer les modèles dans un seul fichier, et j'ai pris quelques minutes depuis le début afin de comprendre comment le diviser en un bon sous-paquetage.

site/models/__init__.py
site/models/book.py

__init__.py ressemble:

from .book import Book

donc je peux encore écrire "de site.importation des modèles du Livre".

Le seul truc, c'est que vous devez définir explicitement chaque modèle de la demande, en raison d'un bogue dans Django: il suppose que le nom de l'application est la troisième à la dernière entrée dans le modèle de chemin de. "du site.modèles.Livre" les résultats dans la partie "site", ce qui est correct; "site.modèles.livre.Livre" fait penser le nom de l'application est "modèles". C'est un méchant assez hack sur Django partie; il faut probablement chercher dans la liste des applications installées pour un préfixe correspondant.

class Book(models.Model):
    class Meta: app_label = "site"

Vous pourriez probablement utiliser une classe de base ou de la métaclasse de généraliser, mais je havn't embêter avec ça pour l'instant.

Answer 2

Django est conçu pour vous permettre de construire de nombreuses petites applications au lieu d'une grosse application.

À l'intérieur de chaque grande application sont nombreuses petites applications de la difficulté d'être libre.

Si votre models.py se sent grand, vous êtes en train de faire trop. Stop. Détendez-vous. Avant de se décomposer.

Trouver plus petit, potentiellement réutilisables petits composants de l'application, ou des morceaux. Vous n'avez pas à effectivement de les réutiliser. Il suffit de penser comme potentiellement réutilisables.

Considérez votre chemins de mise à niveau et de décomposer les applications que vous souhaitez remplacer un jour. Vous n'avez pas à effectivement de les remplacer, mais vous pouvez les considérer comme un stand-alone "module" de programmation qui pourraient se faire remplacer par quelque chose de plus frais dans l'avenir.

Nous avons environ une douzaine d'applications, chaque model.py n'est plus que d'environ 400 lignes de code. Ils sont tous très concentré sur moins d'environ une demi-douzaine de discrètes définitions de classe. (Ce ne sont pas des limites strictes, ils sont des observations au sujet de notre code.)

On décompose tôt et souvent.

Answer 3

Je ne peux pas obtenir assez de laquelle de nombreux problèmes éventuels que vous pourriez avoir. Voici quelques possibilités de réponses:

• plusieurs modèles dans le même fichier

  Les mettre dans des fichiers séparés. Si il y a des dépendances, utilisez l'importation de tirer dans le d'autres modèles.

• étrangères de la logique de l'utilité des fonctions dans models.py

  Mettre de la logique supplémentaire dans des fichiers séparés.

• méthodes statiques pour la sélection de certaines instances de modèle de base de données

  Créer un nouveau Gestionnaire dans un fichier séparé.

• méthodes évidemment en rapport avec le modèle

  enregistrer, __unicode__ et get_absolute_url en sont des exemples.