Este documento explica algunas de las filosofías fundamentales que los desarrolladores de Django han utilizado al crear el framework. Su objetivo es explicar el pasado y guiar el futuro.
Un objetivo fundamental de la pila de Django es acoplamiento suelto y cohesión estrecha. Las diferentes capas del framework no deberían «saber» entre sí a menos que sea absolutamente necesario.
Por ejemplo, el sistema de plantillas no sabe nada sobre solicitudes web, la capa de base de datos no sabe nada sobre la visualización de datos y el sistema de vistas no se preocupa por qué sistema de plantillas utilice un programador.
Aunque Django viene con una pila completa para conveniencia, las piezas de la pila son independientes entre sí siempre que sea posible.
Las aplicaciones de Django deberían utilizar lo menos posible; deberían carecer de boilerplate. Django debería aprovechar al máximo las capacidades dinámicas de Python, como la introspección.
El punto de un marco de trabajo web en el siglo XXI es hacer que los aspectos tediosos del desarrollo web sean rápidos. Django debería permitir una velocidad increíblemente rápida de desarrollo web.
Cada concepto y/o dato distinto debe vivir en un lugar, y solo uno. La redundancia es mala. La normalización es buena.
El marco de trabajo, dentro de lo razonable, debería deducir lo máximo posible a partir de lo mínimo posible.
Ver también
La discusión sobre DRY en el Portland Pattern Repository.
Esto es un principio fundamental de Python listado en PEP 20, y significa que Django no debería hacer demasiada «magia». La magia no debe suceder a menos que haya una buena razón para ello. La magia solo vale la pena usar si crea una gran comodidad inalcanzable de otra manera, y no se implementa de una forma que confunda a los desarrolladores que están tratando de aprender a utilizar el feature.
El marco de trabajo debe ser consistente en todos los niveles. La consistencia se aplica a todo, desde el nivel bajo (el estilo de codificación Python utilizado) hasta el alto (la «experiencia» de utilizar Django).
Los campos no deberían asumir ciertos comportamientos basándose únicamente en el nombre del campo. Esto requiere demasiado conocimiento del sistema y está expuesto a errores. En su lugar, los comportamientos deberían basarse en argumentos de palabra clave y, en algunos casos, en el tipo del campo.
Los modelos deben encapsular todos los aspectos de un «objeto», siguiendo el patrón de diseño Active Record de Martin Fowler.
Esto es por qué tanto la data representada por un modelo como información sobre él (su nombre legible para humanos, opciones como ordenación predeterminada, etc.) se definen en la clase del modelo; toda la información necesaria para entender un modelo dado debe estar almacenada en el modelo.
Los objetivos principales de la API de base de datos son:
Debería ejecutar sentencias SQL lo menos posible y optimizarlas internamente.
Esto es por qué los desarrolladores deben llamar explícitamente a save() en lugar de que el marco guarde cosas detrás de escena silenciosamente.
También es por esto que existe la función select_related() del método QuerySet. Es un acelerador de rendimiento opcional para el caso común de seleccionar «todos los objetos relacionados».
La API de bases de datos debería permitir declaraciones ricas y expresivas en la menor cantidad de sintaxis posible. No debería depender del importación de otros módulos o objetos auxiliares.
Las uniones se deben realizar automáticamente, detrás de escena, cuando sea necesario.
Cada objeto debe poder acceder a cada objeto relacionado, en todo el sistema. Este acceso debe funcionar en ambos sentidos.
La API de bases de datos debería darse cuenta de que es un atajo pero no necesariamente una solución final. El marco debería hacerlo fácil escribir SQL personalizado – declaraciones completas o solo cláusulas WHERE personalizadas como parámetros a las llamadas a la API.
Las URLs en una aplicación Django no deben estar acopladas al código Python subyacente. Unir URLs a nombres de funciones Python es Una Mala Y Fea Cosita.
A lo largo de estas líneas, el sistema de URL de Django debería permitir que las URLs para la misma aplicación sean diferentes en diferentes contextos. Por ejemplo, un sitio puede poner historias en /historias/, mientras que otro puede utilizar /noticias/.
Las URL deben ser lo más flexibles posibles. Se debe permitir cualquier diseño de URL concebible.
El marco debería hacer que sea tan fácil (o incluso más fácil) para un desarrollador diseñar URLs bonitas como feas.
Se deben evitar las extensiones de archivo en las URL de páginas web.
Las comas estilo vignette en las URL merecen una severa condena.
Técnicamente, foo.com/bar y foo.com/bar/ son dos URLs diferentes, y los robots de búsqueda (y algunas herramientas que analizan el tráfico web) las tratarían como páginas separadas. Django debería hacer un esfuerzo por «normalizar» las URL para que los robots de búsqueda no se confundan.
Esto es la razón detrás del APPEND_SLASH parámetro de configuración.
La plantilla del sistema se ve como una herramienta que controla la presentación y la lógica relacionada con la presentación – y eso es todo. El sistema de plantillas no debería apoyar funcionalidades que van más allá de este objetivo básico.
La mayoría de los sitios web dinámicos utilizan algún tipo de diseño común para toda la página – un encabezado común, pie de página, barra de navegación, etc. El sistema de plantillas de Django debería hacer que sea fácil almacenar esos elementos en un solo lugar, eliminando el código duplicado.
Esto es la filosofía detrás de herencia de plantilla.
El sistema de plantillas no debería diseñarse para que solo genere HTML. Debería ser igualmente bueno generando otros formatos de texto basados en texto o simplemente texto plano.
Usar un motor de XML para parsear las plantillas introduce un mundo nuevo de errores humanos al editar las plantillas – y conlleva un nivel inaceptable de sobrecarga en el procesamiento de plantillas.
El sistema de plantillas no debería diseñarse para que las plantillas necesariamente se muestren bien en editores WYSIWYG como Dreamweaver. Eso es demasiado severo de una limitación y no permitiría que el sintaxis fuera tan agradable como lo es. Django espera que los autores de plantillas estén cómodos editando HTML directamente.
El sistema de plantillas no debería hacer cosas mágicas con el espacio en blanco. Si una plantilla incluye espacio en blanco, el sistema debe tratarlo como trata el texto – simplemente mostrarlo. Cualquier espacio en blanco que no esté dentro de un etiqueta de plantilla se mostrará.
El objetivo no es inventar un lenguaje de programación. El objetivo es ofrecer suficiente funcionalidad propia de la programación, como ramificaciones y bucles, que es esencial para tomar decisiones relacionadas con las presentaciones. La Lengua de plantillas de Django (DTL) busca evitar lógica avanzada.
El sistema de plantillas, por defecto, debería prohibir la inclusión de código malicioso —como comandos que eliminan registros de bases de datos—.
Esta es otra razón por la cual el sistema de plantillas no permite código Python arbitrario.
El sistema de plantillas debería reconocer que los autores avanzados de plantillas pueden querer extender su tecnología.
Esta es la filosofía detrás de las etiquetas y filtros de plantillas personalizadas.
La escritura de una vista debería ser tan sencilla como escribir una función de Python. Los desarrolladores no deberían tener que instanciar una clase cuando una función bastaría.
Las vistas deberían tener acceso a un objeto de solicitud – un objeto que almacena metadatos sobre la solicitud actual. El objeto se debería pasar directamente a una función de vista, en lugar de que la función de vista tenga que acceder a los datos de la solicitud desde una variable global. Esto lo hace ligero, limpio y fácil de probar vistas pasando objetos de solicitud «falsos».
Una vista no debería preocuparse por qué sistema de plantillas el desarrollador utilice – o incluso si se utiliza un sistema de plantillas en absoluto.
GET y POST son distintos; los desarrolladores deberían utilizar explícitamente uno u otro. El framework debería hacer fácil distinguir entre datos GET y POST.
Los objetivos principales del marco de caché de Django son:
A la caché debe ser lo más rápido posible. Por tanto, todo el código del marco que rodea la caché de fondo se debe mantener al mínimo absoluto, especialmente para las operaciones get().
La API de caché debería proporcionar una interfaz consistente a través de los diferentes backends de caché.
La API de caché debe ser extensible en el nivel de la aplicación según las necesidades del desarrollador (por ejemplo, ver Transformación de la clave de caché).
may 31, 2026