models.py se está volviendo enorme, ¿cuál es la mejor manera de dividirlo?

Instrucciones de mi supervisor: "Quiero evitar poner lógica en el models.py. De aquí en adelante, usemos eso como clases únicas para acceder a la base de datos, y mantengamos toda la lógica en clases externas que usan las clases de modelos, o envuélvalas".

Siento que este es el camino equivocado. Siento que mantener la lógica fuera de los modelos solo para mantener el archivo pequeño es una mala idea. Si la lógica es mejor en el modelo, ahí es donde realmente debería ir independientemente del tamaño del archivo.

Entonces, ¿hay una forma sencilla de usar inclusiones? En lenguaje PHP, me gustaría proponerle al supervisor que acabamos de models.pyincluir () las clases modelo de otros lugares. Conceptualmente, esto permitiría que los modelos tuvieran toda la lógica que queremos, pero mantener el tamaño de archivo bajo aumentando el número de archivos (lo que conduce a menos problemas de control de revisión como conflictos, etc.).

Entonces, ¿hay una manera simple de eliminar las clases de modelo del archivo models.py, pero aún así hacer que los modelos funcionen con todas las herramientas de Django? ¿O hay una solución completamente diferente pero elegante para el problema general de un archivo models.py "grande"? Se agradecería cualquier aporte.

Django está diseñado para permitirle construir muchas aplicaciones pequeñas en lugar de una gran aplicación.

Dentro de cada aplicación grande hay muchas aplicaciones pequeñas que luchan por ser gratuitas.

Si se models.pysiente grande, está haciendo demasiado. Detener. Relajarse. Descomponer.

Encuentre componentes o piezas de aplicaciones pequeñas más pequeñas y potencialmente reutilizables. Usted no tiene que realmente volver a utilizarlos. Piense en ellos como potencialmente reutilizables.

Considere sus rutas de actualización y descomponga las aplicaciones que quizás desee reemplazar algún día. Usted no tiene que realmente reemplazarlos, pero se puede considerar como un "módulo" independiente de programación que podrían quedar reemplazado con algo más fresco en el futuro.

Tenemos alrededor de una docena de aplicaciones, cada model.pyuna no tiene más de 400 líneas de código. Todos están bastante enfocados en menos de media docena de definiciones de clases discretas. (Estos no son límites estrictos, son observaciones sobre nuestro código).

Nos descomponemos temprano y con frecuencia.

Es natural que las clases de modelo contengan métodos para operar en el modelo. Si tengo un modelo de libro, con un método book.get_noun_count(), ahí es donde pertenece - no quiero tener que escribir " get_noun_count(book)", a menos que el método realmente pertenezca intrínsecamente a algún otro paquete. (Podría, por ejemplo, si tengo un paquete para acceder a la API de Amazon con " get_amazon_product_id(book)").

Me estremecí cuando la documentación de Django sugirió poner modelos en un solo archivo, y me tomé unos minutos desde el principio para descubrir cómo dividirlo en un subpaquete adecuado.

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

__init__.py parece:

from .book import Book

así que todavía puedo escribir "from site.models import Book".

Lo siguiente solo es necesario para versiones anteriores a Django 1.7, consulte https://code.djangoproject.com/ticket/3591

El único truco es que necesita configurar explícitamente la aplicación de cada modelo, debido a un error en Django: asume que el nombre de la aplicación es la penúltima entrada en la ruta del modelo. "site.models.Book" da como resultado "sitio", que es correcto; "site.models.book.Book" hace pensar que el nombre de la aplicación es "modelos". Este es un truco bastante desagradable por parte de Django; probablemente debería buscar en la lista de aplicaciones instaladas una coincidencia de prefijo.

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

Probablemente podría usar una clase base o una metaclase para generalizar esto, pero todavía no me he molestado con eso.

No puedo entender cuál de los muchos posibles problemas puede tener. Aquí hay algunas posibilidades con respuestas:

• varios modelos en el mismo archivo

  Colóquelos en archivos separados. Si hay dependencias, use la importación para extraer los modelos adicionales.

• funciones de utilidad / lógica extraña en models.py

  Coloque la lógica adicional en archivos separados.

• métodos estáticos para seleccionar algunas instancias de modelo de la base de datos

  Cree un nuevo administrador en un archivo separado.

• métodos obviamente relacionados con el modelo

  save, __unicode__ y get_absolute_url son ejemplos.