models.py hacerse grande, ¿cuál es la mejor manera de romperlo?

Question

Instrucciones de mi supervisor: "Quiero evitar poner cualquier lógica en el models.py. A partir de ahora, vamos a usar eso como únicas clases para acceder a la base de datos, y mantener toda la lógica en clases externas que usan las clases de modelos, o envuélvalos ".

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 la mejor en el modelo, allí es donde realmente debería ir, independientemente del tamaño del archivo.

¿Existe una forma sencilla de usar? En PHP-speak, me gustaría proponerle al supervisor que solo tenemos models.py include() las clases modelo de otros lugares. Conceptualmente, esto permitiría a los modelos tener toda la lógica que queremos, pero manteniendo el tamaño del archivo reducido al aumentar la cantidad de archivos (lo que lleva a menos problemas de control de revisiones como conflictos, etc.).

Entonces, ¿hay una forma simple de eliminar las clases de modelo del archivo models.py, pero aún así los modelos funcionan con todas las herramientas de Django? ¿O hay una solución completamente diferente pero elegante para el problema general de un archivo "grande" de models.py? Cualquier entrada sería apreciada.

Answer 1

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

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

Si su models.py se siente grande, está haciendo demasiado. Detener. Relajarse. Descomponer.

Encuentra componentes de pequeña aplicación pequeños y potencialmente reutilizables, o piezas. No es necesario que realmente reutilizarlos. Solo 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. No es necesario que realmente los reemplace, pero puede considerarlos como un "módulo" independiente de programación que podría reemplazarse por algo más frío en el futuro.

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

Nos descomponemos temprano y con frecuencia.

Answer 2

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 con 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 encogí cuando la documentación de Django sugirió poner modelos en un solo archivo, y tardé 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 

por lo que todavía puede escribir "de site.models importar libro".

---

La siguiente información sólo se requiere para las versiones anteriores a Django 1.7, ver https://code.djangoproject.com/ticket/3591

El único truco es que es necesario establecer 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 que piense que el nombre de la aplicación es "modelos". Este es un hack 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 se podría utilizar una clase base o metaclase generalizar esto, pero no me he molestado con eso todavía.

Answer 3

No puedo entender cuál de los muchos posibles problemas que pueda tener. He aquí algunas posibilidades con las respuestas:

• varios modelos en el mismo archivo

  ponerlas en archivos separados. Si hay dependencias, use importar para obtener los modelos adicionales .

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

  poner la lógica adicional en archivos separados.

• métodos estáticos de selección de algunas instancias de modelo de base de datos

  Crear un nuevo Manager en un archivo separado.

• métodos obviamente relacionado con el modelo

  guardar, __unicode__ y get_absolute_url son ejemplos.