¿Cómo gestionas tus aplicaciones de Django?

Question

Solo quería intentar construir un proyecto con django. Por lo tanto, tengo una pregunta (básica) sobre cómo administrar tal proyecto. Ya que no puedo encontrar ninguna guía o más sobre cómo dividir un proyecto en aplicaciones.

Tomemos una especie de SO como ejemplo. ¿Qué aplicaciones usarías? Diría que deberían ser las aplicaciones "usuarios" y "preguntas". Pero, ¿y si hubiera un sistema de temas con artículos estáticos también? Tal vez ellos también podrían recibir votos. ¿Cómo construir la estructura de aplicaciones? ¿Una aplicación para "preguntas", "votos" y "temas" o solo una aplicación "contenido"?

No tengo ni idea de qué hacer. Tal vez es porque todavía no sé mucho sobre Django, pero estoy interesado ...

Answer 1

Te diré cómo me estoy acercando a esa pregunta: normalmente me siento con una hoja de papel y dibujo las cajas (funcionalidades) y flechas (interdependencias entre funcionalidades). Estoy seguro de que hay metodologías u otras cosas que podrían ayudarlo, pero mi enfoque generalmente me funciona (YMMV, por supuesto).

Sin embargo, saber lo que se supone que es un sitio es básico. ;)

Answer 2

Debe intentar separar el proyecto en la mayor cantidad de aplicaciones posible. Para la mayoría de los proyectos, una aplicación no contendrá más de 5 modelos. Por ejemplo, un proyecto como SO tendría aplicaciones separadas para UsersProfiles, Questions, Tags (hay uno listo en django para esto), etc. Si hubiera un sistema con páginas estáticas que sería una aplicación separada también (hay listas) para este propósito). También debe probar y hacer que sus aplicaciones sean lo más genéricas posible, para poder reutilizarlas en otros proyectos. Hay un buen presentation en aplicaciones reutilizables.

Answer 3

Al igual que en cualquier conjunto de dependencias ... intente encontrar los aspectos independientes más útiles del proyecto y cree esas aplicaciones independientes. Otras aplicaciones de Django tendrán una funcionalidad de nivel superior y reutilizarán las partes de las aplicaciones de nivel más bajo que hayas configurado.

En mi proyecto, tengo una aplicación de calendario con su propio objeto Evento en sus modelos. También tengo una configuración de base de datos de viajes compartidos, y para la hora de salida y la duración utilizo el objeto de evento del calendario directamente en mis tablas de RideShare. La base de datos de uso compartido del automóvil es compatible con el calendario, y obtiene todas las bonitas vistas de exportación y calendario de .ics desde la aplicación de calendario para 'gratis'.

Existen algunos trucos para volver a las aplicaciones reutilizables, como nombrar el directorio de plantillas: project/app2/templates/app2/index.html. Esto le permite consultar app2/index.html desde cualquier otra aplicación y obtener la plantilla correcta. Escogí esa mirando las aplicaciones reutilizables incorporadas en Django. Pinax es un poco monstruo en cuanto a tamaño, pero también demuestra una agradable estructura de aplicación reutilizable.

En caso de duda, olvídese de las aplicaciones reutilizables por el momento. Coloque todos sus mensajes y encuestas en una aplicación y obtenga una rev. Durante el proceso, descubrirá qué pasos son innecesarios y podría aparecer como algo independiente en el futuro.

Answer 4

No existen reglas estrictas, pero diría que es mejor errar por el lado de aplicaciones más especializadas. Idealmente, una aplicación debería manejar solo una preocupación funcional: es decir, "etiquetar" o "comentar" o "auth/auth" o "publicaciones". Este tipo de diseño también le ayudará a reutilizar las aplicaciones de código abierto disponibles en lugar de reinventar la rueda (es decir, Django viene con las aplicaciones auth y comments, django-tagging o django-taggable, casi con seguridad puede hacer lo que necesita, etc.).

Generic foreign keys puede ayudarlo a desacoplar aplicaciones como el etiquetado o los comentarios que podrían aplicarse a modelos de varias otras aplicaciones.

Answer 5

Una buena pregunta que debes hacerte al decidir si escribir o no una aplicación es "¿podría usar esto en otro proyecto?". Si cree que podría hacerlo, considere lo que se necesitaría para que la aplicación sea lo más independiente posible; ¿Cómo se pueden reducir las dependencias para que la aplicación no dependa de nada específico para un proyecto en particular?

Algunas de las maneras que usted puede hacer esto son:

• Dar a cada uno su propia aplicación urls.py
• Permitir que los tipos de modelo que se pasan como parámetros en lugar de declarar explícitamente qué modelos se utilizan en su puntos de vista. Las vistas genéricas usan este principio.
• Haz que tus plantillas se anulen fácilmente teniendo algún tipo de parámetro template_name pasado en tu urls.py
• Asegúrate de que puedes hacer búsquedas reversas de URL con tus objetos y vistas. Esto significa nombrar sus vistas en los métodos urls.py y crear get_absolute_url en sus modelos.
• En algunos casos, como el etiquetado, GenericForeignKeys se puede utilizar para asociar un modelo en su aplicación a cualquier otro modelo, independientemente de si ForeignKeys lo "mira hacia atrás".