El Ciclo de Solicitud MTV de Django y la Pereza del ORM

Django denomina su propia arquitectura MTV: Modelo, Plantilla, Vista.

Ese nombre causa más confusión de la que resuelve, porque la "Vista" de Django es el controlador en el sentido clásico de MVC, y el propio Django -el resolvedor de URL y los internos del framework- juega el papel que MVC asigna a la "vista".

Debajo de esa peculiaridad de nomenclatura se encuentra una arquitectura real: cada solicitud pasa a través de una pila anidada de middleware, se enruta a una función o clase de vista, y esa vista típicamente habla con modelos cuyos querysets son perezosos por diseño.

Esta página es el modelo mental detrás de ambas mitades: cómo una solicitud realmente se mueve a través de Django y por qué el ORM se comporta como lo hace una vez que una vista comienza a consultarlo.

Conceptos básicos de Django cubre la configuración de proyectos y aplicaciones de forma práctica; Modelos y el ORM y Migraciones profundizan en la capa de datos que esta página introduce conceptualmente.

Resumen

• Una solicitud de Django fluye a través de una pila de middleware anidada hasta una vista, que coordina consultas de modelos y plantillas evaluadas perezosamente, y la respuesta fluye de regreso a través del mismo middleware en orden inverso.
• Por qué Importa: La mayoría de los errores de rendimiento de Django (consultas N+1) y la mayoría de los errores de middleware (orden incorrecto) provienen directamente de no comprender estas dos mecánicas, no de que Django en sí sea impredecible.
• Conceptos Clave: el patrón MTV, la cebolla de middleware, el resolvedor de URL, la pereza del QuerySet, las migraciones como estado del esquema rastreado.
• Cuándo Usar Este Modelo: Decidir dónde debe ubicarse el middleware en MIDDLEWARE, depurar por qué un queryset ejecutó más SQL de lo esperado o explicar por qué makemigrations y migrate son dos pasos separados.
• Limitaciones / Compensaciones: La pereza del ORM y la cebolla de middleware intercambian explicidad por conveniencia: hacen que el código simple sea simple, pero ocultan cuándo ocurre realmente un viaje de ida y vuelta a la base de datos o una mutación de respuesta.
• Temas Relacionados: el patrón MVC clásico, la capa de serialización de Django REST Framework, el despacho de solicitudes WSGI/ASGI, la planificación de consultas SQL.

Fundamentos

La nomenclatura MTV de Django es una fuente de confusión casi permanente para cualquiera que venga de frameworks MVC: en Django, el Modelo es la misma idea que el modelo de MVC, pero la Plantilla de Django es la "vista" de MVC (la capa de renderizado), y la Vista de Django es el "controlador" de MVC (la lógica que decide qué renderizar).

El propio Django -específicamente el resolvedor de URL- ocupa el papel que MVC llama "vista" en el sentido de coordinar todo, razón por la cual alguna documentación llama al enfoque de Django un patrón MTV o "MVT" en lugar de afirmar una equivalencia MVC directa.

El viaje de una solicitud comienza en el punto de entrada WSGI (o ASGI, en despliegues con capacidad asíncrona), pasa a través de cada middleware configurado en orden, se compara con los patrones de urls.py para encontrar una vista, y el valor de retorno de la vista viaja de regreso a través de la misma pila de middleware en orden inverso.

El middleware en Django no es una cadena plana como la de Express; es una cebolla anidada: cada middleware envuelve al siguiente, por lo que un middleware puede ejecutar código tanto antes de que la vista se ejecute (mientras la solicitud entra) como después de que regrese (mientras la respuesta sale).

Solicitud  -> [SecurityMiddleware -> [SessionMiddleware -> [CommonMiddleware -> Vista] ] ]
Respuesta <- [SecurityMiddleware <- [SessionMiddleware <- [CommonMiddleware <- Vista] ] ]

Esa anidación es la razón por la que el orden en la lista MIDDLEWARE importa en ambas direcciones: un middleware cerca de la parte superior de la lista se ejecuta primero al entrar, pero último al salir, envolviendo todo lo que está debajo.

Mecánicas e Interacciones

Una vez que una vista comienza a trabajar con modelos, el comportamiento que más sorprende a los recién llegados es que un QuerySet no ejecuta ningún SQL cuando se define.

Article.objects.filter(status="live") construye una descripción de consulta, no un resultado; el SELECT real solo se dispara cuando algo fuerza la evaluación: iterarlo, cortarlo de una manera que no sea un filtro adicional, llamar a list() sobre él, verificar su veracidad o acceder a len().

Esta pereza es lo que hace que las llamadas encadenadas como .filter().exclude().order_by() funcionen sin tres viajes de ida y vuelta: cada llamada devuelve un QuerySet nuevo y aún no evaluado, y solo el punto de evaluación final toca la base de datos.

Sin embargo, la pereza tiene un costo bien conocido: acceder al campo de un objeto relacionado dentro de un bucle (book.author.name para cada book en un queryset) activa una consulta por iteración, porque el objeto relacionado se recupera perezosamente la primera vez que se toca; este es el clásico problema de consulta N+1, y existe específicamente porque la pereza hace que sea fácil escribir código que parece un simple acceso a atributos pero que emite silenciosamente una consulta.

select_related (para ForeignKey/OneToOne, a través de un JOIN SQL) y prefetch_related (para ManyToMany/ForeignKey inverso, a través de una segunda consulta y unión en Python) existen para colapsar ese patrón N+1 en una o dos consultas, pero deben solicitarse explícitamente: Django no infiere el patrón de acceso con anticipación.

from django.db import models
 
class Author(models.Model):
    name = models.CharField(max_length=120)
 
class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
 
# Una consulta total, no una consulta por libro:
Book.objects.select_related("author").filter(author__name__startswith="A")

Las migraciones siguen un modelo relacionado pero distinto: Django rastrea el estado de cada modelo a partir de la última migración, y makemigrations genera un nuevo archivo de migración comparando el código de su modelo actual con ese estado rastreado; no lee el esquema de la base de datos en vivo para decidir qué cambió.

Luego, migrate aplica los archivos de migración pendientes a la base de datos real, en el orden de dependencia registrado dentro de cada migración, razón por la cual las migraciones son archivos que se confirman en el control de versiones en lugar de un paso de sincronización automática en tiempo de ejecución.

Consideraciones Avanzadas y Aplicaciones

El ORM de Django fue diseñado principalmente para sincronización, y esa suposición todavía da forma a las vistas asíncronas: Django agregó soporte para vistas async def y despliegue ASGI, pero los métodos de consulta del ORM en gran medida siguen siendo síncronos, por lo que una vista asíncrona que consulta la base de datos necesita un puente sync_to_async (o uno de los métodos ORM asíncronos más nuevos agregados en lanzamientos recientes) en lugar de obtener E/S asíncrona nativa de forma gratuita.

Eso significa que "mi vista es async def" no significa automáticamente "mi acceso a la base de datos no bloquea" - consulte Vistas Asíncronas y Canales para saber dónde se encuentra realmente ese límite.

El sitio de administración es un pago directo de la introspección de la capa de modelo: admin.site.register(Model) funciona porque Django puede leer los campos, relaciones y validadores de un modelo para generar formularios CRUD sin ningún código específico de administración, razón por la cual el administrador tampoco es una buena opción como interfaz pública: expone exactamente la forma de sus modelos, no una interfaz curada.

La caché interactúa con ambas mitades de este modelo: la caché a nivel de middleware (UpdateCacheMiddleware/FetchFromCacheMiddleware) envuelve respuestas completas utilizando la misma mecánica de cebolla descrita anteriormente, mientras que la caché a nivel de queryset solo se aplica dentro de la caché de resultados de una instancia de QuerySet evaluada, no entre solicitudes - consulte Caché y Rendimiento.

Conceptos Erróneos Comunes

• "MTV es solo el nombre de Django para MVC." El mapeo no es uno a uno: la "Plantilla" de Django desempeña el papel que MVC llama "vista" (renderizado), y la "Vista" de Django desempeña el papel que MVC llama "controlador" (lógica de manejo de solicitudes), lo que es lo opuesto a lo que sugiere la palabra compartida "vista".
• "Un QuerySet ejecuta su consulta tan pronto como lo escribes." No ejecuta ningún SQL hasta que algo fuerza la evaluación: iteración, list(), segmentación (de una manera que no filtra), una verificación booleana/de longitud, que es lo que permite el encadenamiento seguro de métodos en primer lugar.
• "Las migraciones mantienen la base de datos sincronizada automáticamente." makemigrations solo genera archivos de migración comparando el código de modelo actual con el estado del modelo rastreado de Django; alguien (o un paso de despliegue) todavía tiene que ejecutar migrate para que la base de datos cambie realmente.
• "El orden del middleware en MIDDLEWARE apenas importa." Debido a que el middleware se anida como una cebolla, el cambio de orden afecta tanto cuándo se ejecuta el código antes de la vista como cuándo se ejecuta el código después de la vista, por lo que el middleware relacionado con la seguridad y las sesiones depende particularmente de un orden estricto.
• "Las vistas asíncronas hacen que el acceso a la base de datos de Django sea asíncrono." Las funciones de vista pueden declararse async def, pero la mayoría de la ejecución de consultas del ORM sigue siendo síncrona internamente y necesita un puente explícito para ejecutarse de forma segura dentro de una vista asíncrona.

Preguntas Frecuentes

Relacionados

• Conceptos básicos de Django - proyectos, aplicaciones, URLs y vistas de forma práctica
• Modelos y el ORM - campos, relaciones y patrones de queryset en profundidad
• Migraciones - cómo se generan y aplican los archivos de migración
• Caché y Rendimiento - caché a nivel de middleware y a nivel de queryset
• Vistas Asíncronas y Canales - el límite asíncrono/síncrono del ORM en la práctica
• Django REST Framework - una capa de serialización construida sobre este mismo ciclo de solicitud

Versiones de la pila: Esta página fue escrita para Django 5.2 en Python 3.14 (mantenimiento: 3.13).