Cada "aplicación" debe ser pequeña: una única entidad reutilizable más algunas tablas asociadas. Tenemos alrededor de 5 más/menos 2 tablas por modelo de aplicación. La mayoría de nuestras aplicaciones de media docena son más pequeñas que 5 tablas. Uno tiene cero tablas en el modelo.
Cada aplicación debe diseñarse para ser un concepto reutilizable. En nuestro caso, cada aplicación es una parte del sitio general; las aplicaciones podrían eliminarse y reemplazarse por separado.
De hecho, esa es nuestra estrategia. A medida que nuestros requisitos se amplían y maduran, podemos eliminar y reemplazar aplicaciones de manera independiente.
Está bien que las aplicaciones dependan entre sí. Sin embargo, la dependencia debe limitarse a las cosas obvias como "modelos" y "formas". Además, las aplicaciones pueden depender de los nombres en las URL de los demás. En consecuencia, sus URL nombradas deben tener un formulario como "vista de aplicación" para que la función reverse
o la etiqueta {% url %}
puedan encontrarlas correctamente.
Cada aplicación debe contener es comandos propios lotes (por lo general a través de un comando formal que puede ser encontrado por el script django-admin
.
Finalmente, todo lo que es más compleja que un simple modelo o la Forma que es compartida probablemente no pertenece a cualquiera de las aplicaciones, pero debe ser una biblioteca compartida por separado. Por ejemplo, usamos XLRD, pero envolvemos partes de nuestra clase para que se parezca más al módulo csv
incorporado. Este envoltorio para XLRD no es una parte adecuada de cualquier aplicación, es un módulo aparte, fuera de las aplicaciones de Django.
Estoy de acuerdo ... Las cosas que aprendí al trabajar en pinax y satchmo son invaluables – Jiaaro