vitor style rest_api mtv example python django design

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



user types django (6)

¿Cuál es la mejor forma de diseñar un gran proyecto 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 sobre por qué un determinado diseño de proyecto 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.

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

Esta página hace un buen trabajo al abordar 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 personalizados, debe crear un subdirectorio en el directorio de la aplicación denominado templatetags, y debe contener un archivo llamado __init__.py para que pueda importarse como un módulo de Python.
  2. Para definir pruebas unitarias que el marco de prueba de Django notará automáticamente, 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 las pruebas (el directorio) también se aplica a los modelos, lo que ayuda a resolver el problema de tener que pasar por 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.

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 único 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 colisiones de nombres de plantilla 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 aún no he visto un estándar emergente (la forma en que hacen las cosas en 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 - verifique los docs .

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

Mi diseño actual proviene de 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.

Creé 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 de desarrollo de aplicaciones y en la carpeta de plantillas correspondiente. Cuando tengo algo con lo que estoy contento, etiqueto esa revisión y actualizo prod.