Diseño de proyecto/diseño de FS para grandes proyectos de django

Question

¿Cuál es la mejor forma de diseñar un gran proyecto de django? Los tutoriales proporcionan instrucciones sencillas para configurar aplicaciones, modelos y vistas, pero hay menos información sobre cómo se deben desglosar las aplicaciones y los proyectos, cuánto compartir es permisible/necesario entre aplicaciones en un proyecto típico (obviamente eso depende en gran medida de el proyecto) y cómo/dónde se deben guardar las plantillas generales.

¿Alguien tiene ejemplos, sugerencias y explicaciones en cuanto a por qué un diseño de proyecto determinado es mejor que otro? Estoy particularmente interesado en la incorporación de un gran número de pruebas unitarias (2-5 veces el tamaño de la base de código real) y plantillas/externalización de cadenas.

Answer 1

Las principales pautas son similares a cualquier otro proyecto de código grande. Las aplicaciones deben abordar una responsabilidad única y claramente definida. El nombre "aplicación" es un nombre inapropiado; Las aplicaciones de Django deberían considerarse más como componentes reutilizables que se pueden conectar para crear una aplicación real. Las pruebas para cada aplicación deben estar contenidas dentro de esa aplicación. Las aplicaciones deben estar desacopladas entre sí tanto como sea posible, pero es evidente que habrá dependencias, por lo que el objetivo debe ser mantener el gráfico de dependencia lo más simple y sensato posible.

Prefiero mantener todas las plantillas para un proyecto en un solo directorio de plantillas para todo el proyecto, con un subdirectorio para cada aplicación (usar un subdirectorio de plantilla para cada aplicación es una convención muy fuerte en Django, ya que evita el nombre de la plantilla colisiones entre aplicaciones). El motivo de un único directorio de plantillas para todo el proyecto es que las plantillas, los árboles de herencia de plantillas y los nombres de bloques pueden ser bastante específicos del proyecto, por lo que es difícil proporcionar plantillas de aplicaciones "predeterminadas" que puedan conectarse a cualquier proyecto.Ha habido algunos intentos de establecer convenciones de nomenclatura estándar para las plantillas base de todo el sitio y los bloques que definen, pero no he visto un estándar emerger aún (la forma en que hacen las cosas al Pinax es probablemente lo más cercano que tenemos a un estándar).

Re "externalización de cadena", si se refiere a i18n y l10n, Django tiene un fuerte soporte para eso y lugares estándar donde coloca los archivos .po - marque el docs.

Answer 2

Esta página hace un buen trabajo de hacer frente a algunas de mis preguntas: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Específicamente:

1. Para definir etiquetas o filtros de plantilla personalizada, debe crear un subdirectorio en la aplicación de directorio llamado templatetags, y debe contener un archivo llamado __init__.py para que pueda importarse como un módulo de Python.
2. Para definir las pruebas unitarias que serán notadas automáticamente por el marco de prueba de Django, colóquelas en un módulo llamado pruebas (que puede ser un archivo denominado tests.py o un directorio llamado tests). El marco de prueba también encontrará todos los doctests en ese módulo, pero el lugar preferido para ellos es, por supuesto, los documentos de las clases o funciones que están diseñados para probar.
3. Para proporcionar SQL personalizado que se ejecutará inmediatamente después de que se instale su aplicación, cree un subdirectorio llamado sql dentro del directorio de la aplicación; los nombres de los archivos deben ser los mismos que los de las tablas en las que operarán; por ejemplo, si tiene una aplicación llamada weblog que contiene un modelo llamado Entry, entonces el archivo sql/entry.sql dentro del directorio de la aplicación se puede usar para modificar o insertar datos en la tabla de entradas tan pronto como se haya creado.

La nota sobre tests.py y pruebas (el directorio) se cumple también para los modelos, lo que ayuda a solucionar el problema de tener forma de muchas pruebas (o modelos) para un archivo.

Todavía me gustaría ver algunos ejemplos/sugerencias para el desglose de aplicaciones/proyectos, y grandes sitios django que funcionan bien.

Answer 3

La Pinax project se basa en la idea de pequeñas aplicaciones reutilizables, que se combinan fácilmente en un proyecto. Han utilizado el proyecto Cloud 27 como un proyecto de demostración.

El proyecto Django en el que estoy trabajando (llamado Basie, es anterior a 0.1, por lo que no hay ningún enlace aún) está intentando seguir el modelo Pinax, y hasta ahora funciona bastante bien.

Answer 4

Mi diseño actual se debe a que quiero tener una versión de prueba de mis sitios. Esto significa tener dos proyectos para cada sitio, ya que necesitan diferentes configuraciones y me obliga a mover todas las aplicaciones fuera de los proyectos.

He creado dos carpetas: $ APP_ROOT/devel y $ APP_ROOT/prod. Estos contienen todas las aplicaciones. Usando el control de fuente (en mi caso, git) tengo las aplicaciones en desarrollo en la revisión HEAD, mientras que las aplicaciones en prod están bloqueadas en la etiqueta PROD. Las plantillas también tienen su propia carpeta con el mismo diseño que las aplicaciones.

Ahora puedo hacer todo mi desarrollo en la carpeta devel-apps y en la carpeta de plantillas correspondiente. Cuando tengo algo con lo que estoy contento, etiqueto esa revisión y actualizo prod.

Answer 5

me encontré con la disposición de Zachary bastante útil Zachary Voase’s Blog » Django Project Conventions, Revisited.

Answer 6

me gusta mucho Randall Degges' post sobre este tema. Él omite información sobre cómo pegar los archivos de configuración, pero tendré una publicación en la que podré vincular, pero por ahora cualquiera puede consultar my repo donde incluyo alguna dirección en el archivo léame.