Gran diseño de la aplicación Django

Question

Estoy en un equipo que desarrolla un portal universitario basado en la web, que se basará en Django. Todavía estamos en las etapas de exploración, y estoy tratando de encontrar la mejor manera de establecer el entorno de proyecto/desarrollo.

Mi idea inicial es desarrollar el sistema como una "aplicación" Django, que contiene sub-aplicaciones para separar las diferentes partes del sistema. La razón por la que pretendo hacer estas aplicaciones "secundarias" es que no tendrían ningún uso fuera de la aplicación principal en absoluto, por lo que no tendría sentido distribuirlas por separado. Creemos que el portal se instalará en múltiples ubicaciones (en diferentes universidades, por ejemplo), por lo que la aplicación principal se puede incluir en varios proyectos de Django para instalarla. Por lo tanto, tenemos un repositorio diferente para cada proyecto de ubicación, que en realidad es solo un archivo settings.py que define las aplicaciones del portal instaladas, y un urls.py que enruta las direcciones URL a él.

Empecé a escribir algunos códigos iniciales, sin embargo, y me encontré con un problema. Parte del código que maneja la autenticación de usuario y los perfiles parece no tener un hogar. No pertenece conceptualmente a la aplicación del portal, ya que no se relaciona con la funcionalidad del portal. También, sin embargo, no puede ir en el repositorio del proyecto, ya que entonces estaría duplicando el código sobre el repositorio de cada ubicación. Si descubriera un error en este código, por ejemplo, tendría que replicar manualmente el arreglo sobre todos los archivos de proyecto de la ubicación.

Mi idea para una solución es hacer que todos los repos proyectos sean una bifurcación de un proyecto de ubicación "maestro", de modo que pueda extraer cualquier cambio de ese maestro. Creo que esto es complicado, y significa que tengo un repositorio más para cuidar.

Estoy buscando una mejor manera de lograr este proyecto. ¿Alguien puede recomendar una solución o un ejemplo similar que pueda ver? El problema parece ser que estoy desarrollando un proyecto Django en lugar de solo una aplicación Django .

Answer 1

La mejor manera que he encontrado para hacer esto es crear aplicaciones y luego un proyecto para unirlas. La mayoría de mis proyectos tienen aplicaciones similares que están incluidas en cada uno. Correos electrónicos, notas, recordatorios de acción, autenticación de usuario, etc. Mi diseño preferido es de esta manera:

• proyecto/
  • settings.py
  • urls.py
  • views.py
  • ...
• aplicaciones/
  • correos electrónicos/
    • urls.py
    • views.py
    • ...
  • notas/
    • urls.py
    • views.py
    • . ..
  • ...

aplicaciones:

Cada una de las "aplicaciones" vale por sí mismo, y que no sea una settings.py, no se basa en el proyecto en sí (aunque puede confiar en otras aplicaciones). Una de las aplicaciones es la autenticación y administración del usuario. Tiene todas las URL para llevar a cabo sus tareas en apps/auth/urls.py. Todas sus plantillas están en apps/auth/templates/auth/. Toda su funcionalidad es autónoma, de modo que cuando necesito modificar algo, sé a dónde ir.

proyecto:

El project/ contiene todos el pegamento necesario para poner estas aplicaciones individuales en forma conjunta en el proyecto final. En mi caso, hice uso pesado de settings.INSTALLED_APPS en project/ para discernir qué vistas de las aplicaciones tenía disponibles.De esta forma, si tomo apps.notes de mi INSTALLED_APPS, todo funciona de maravilla, sin notas.

Mantenimiento:

Este diseño/metodología/plan también tiene efectos positivos a largo plazo ramificaciones. Puede volver a utilizar cualquiera de las aplicaciones más adelante, casi sin trabajo. Puede probar el sistema de abajo hacia arriba, asegurándose de que cada una de las aplicaciones funcione según lo previsto antes de integrarse en el todo, ayudándole a encontrar/corregir errores más rápidamente. Puede implementar una característica nueva sin implementarla en las instancias existentes de la aplicación (si no está en el INSTALLED_APPS, no pueden verla).

Estoy seguro de que hay formas mejor documentadas de diseñar un proyecto, y maneras más ampliamente utilizadas, pero esta es la que mejor me ha funcionado hasta ahora.

Answer 2

Usted debe echar un vistazo a:

• Django generic relations
• Django reusable apps mejores prácticas si desea volver a utilizar
• GIT o cualquier otro CVS (GIT es ideal para el mantenimiento + despliegue)
• Fabric si necesita implementaciones automatizadas/actualizaciones

Yo suelo usar esta estructura del proyecto:

• /djangoproject
  • /aplicaciones
    • /MAIN # el código principal
    • /estática # cada aplicación sub puede servir estática
    • /aplicación1
    • /estática # cada aplicación secundaria puede servir estática
    • /app2 ...
  • /scripts # manage.py, wsgi, apache.conf, fabfile.py ...
  • /core # bibliotecas ...
  • settings.py
  • local_settings.py

Cada aplicación en/aplicaciones tienen un urls.py eso autoincluded en el principal urls.py . Y cada aplicación puede ser un submódulo de git (o svn externo)

Además, al usar git, puede trabajar en diferentes ramas paralelas (master/dev/customerA/customerB ...) y fusionar actualizaciones.

Crear real reutilizable no es tan fácil con django.

Answer 3

Puede extraer la funcionalidad común en un módulo separado y hacer que sus aplicaciones dependen de ella:

• my_portal
• auth_module
• profiles_module
• Application1 (depende de auth_module)
• application2 (depende de auth_module y profiles_module)

Creo que el hecho de que un proyecto 'clásico' de Django parezca 'contener' las aplicaciones que está utilizando le impide ver la imagen; de hecho, no es necesario. Para un proyecto en el que vas a tener algún tipo de módulo conectable, te sugiero que organices las aplicaciones como huellas y uses zc.buildout + djangorecipe para administrar todo.

De esta manera podrá mantener sus módulos en una estructura plana de un nivel. Los huevos tienen la capacidad de especificar dependencias, por lo que si instala la aplicación 1 (ver arriba), auth_module se instalará automáticamente.

También será fácil tener diferentes configuraciones desplegadas en diferentes servidores. Supongamos, usted tiene server1 que se ha instalado y Application1 servidor2 que tiene tanto Application1 y application2 instalado - sólo puede tener dos configuraciones:

server1.cfg:

[buildout] 
extends = base_deployment.cfg 
eggs += application1 

server2.cfg:

[buildout] 
extends = base_seployment.cfg 
eggs += application1 
     application2 

djangorecipe también le permite especificar diferentes archivos de configuración para cada configuración de buildout, por lo que podrá agregar los bits necesarios a las URL del proyecto principal y a la configuración de las aplicaciones instaladas.

Sin mencionar que también puede tener una configuración separada para la configuración de desarrollo (con debug = True y Django Debug Toolbar instalado, por ejemplo).