O Ciclo de Requisição MTV do Django e a Preguiça do ORM

O Django chama sua própria arquitetura de MTV: Model, Template, View.

Esse nome causa mais confusão do que resolve, porque o "View" do Django é a camada de controle no sentido clássico do MVC, e o próprio Django - o resolvedor de URL e os internos do framework - desempenha o papel que o MVC atribui à "view".

Por baixo dessa peculiaridade de nomenclatura, existe uma arquitetura real: cada requisição passa por uma pilha aninhada de middleware, é roteada para uma função ou classe de view, e essa view tipicamente conversa com modelos cujos querysets são preguiçosos por design.

Esta página é o modelo mental por trás de ambas as partes: como uma requisição realmente se move através do Django e por que o ORM se comporta da maneira que se comporta assim que uma view começa a consultá-lo.

O Django Basics cobre a configuração de projetos e aplicativos na prática; Models & the ORM e Migrations aprofundam a camada de dados que esta página introduz conceitualmente.

Resumo

• Uma requisição Django flui através de uma pilha de middleware aninhada até uma view, que coordena consultas de modelo e templates avaliados preguiçosamente, e a resposta flui de volta através do mesmo middleware em ordem inversa.
• Por que Importa: A maioria dos bugs de performance do Django (consultas N+1) e a maioria dos bugs de middleware (ordem incorreta) vêm diretamente do mal-entendido dessas duas mecânicas, não do próprio Django ser imprevisível.
• Conceitos-Chave: o padrão MTV, a cebola de middleware, o resolvedor de URL, a preguiça do QuerySet, migrações como estado de esquema rastreado.
• Quando Usar Este Modelo: Ao decidir onde o middleware deve ficar em MIDDLEWARE, depurando por que um queryset executou mais SQL do que o esperado, ou explicando por que makemigrations e migrate são duas etapas separadas.
• Limitações / Trade-offs: A preguiça do ORM e a cebola de middleware trocam explicitude por conveniência - elas tornam o código simples fácil, mas escondem exatamente quando uma viagem de ida e volta ao banco de dados ou uma mutação de resposta realmente acontece.
• Tópicos Relacionados: o padrão MVC clássico, a camada de serialização do Django REST Framework, o despacho de requisições WSGI/ASGI, o planejamento de consultas SQL.

Fundamentos

A nomenclatura MTV do Django é uma fonte de confusão quase permanente para quem vem de frameworks MVC: no Django, o Model é a mesma ideia do model do MVC, mas o Template do Django é a "view" do MVC (a camada de renderização), e a View do Django é o "controller" do MVC (a lógica que decide o que renderizar).

O próprio Django - especificamente o resolvedor de URL - ocupa o papel que o MVC chama de "view" no sentido de coordenar tudo, razão pela qual alguma documentação chama a abordagem do Django de padrão MTV ou "MVT" em vez de afirmar uma equivalência MVC direta.

A jornada de uma requisição começa no ponto de entrada WSGI (ou ASGI, em implantações com capacidade assíncrona), passa por todo o middleware configurado em ordem, é comparada com os padrões de urls.py para encontrar uma view, e o valor de retorno da view viaja de volta pela mesma pilha de middleware em ordem inversa.

O Middleware no Django não é uma cadeia plana como a do Express; é uma cebola aninhada: cada middleware envolve o próximo, de modo que um middleware pode executar código tanto antes da view ser executada (enquanto a requisição entra) quanto depois que ela retorna (enquanto a resposta sai).

Requisição  -> [SecurityMiddleware -> [SessionMiddleware -> [CommonMiddleware -> View] ] ]
Resposta <- [SecurityMiddleware <- [SessionMiddleware <- [CommonMiddleware <- View] ] ]

Esse aninhamento é o motivo pelo qual a ordem na lista MIDDLEWARE importa em ambas as direções: um middleware próximo ao topo da lista é executado primeiro na entrada, mas por último na saída, envolvendo tudo abaixo dele.

Mecânicas e Interações

Assim que uma view começa a trabalhar com models, o comportamento que mais surpreende os novatos é que um QuerySet não executa nenhum SQL quando é definido.

Article.objects.filter(status="live") constrói uma descrição de consulta, não um resultado; o SELECT real só dispara quando algo força a avaliação - iterá-lo, fatiá-lo de uma forma que não seja um filtro adicional, chamar list() nele, verificar sua veracidade, ou acessar len().

Essa preguiça é o que faz com que chamadas encadeadas como .filter().exclude().order_by() funcionem sem três viagens de ida e volta: cada chamada retorna um novo QuerySet ainda não avaliado, e apenas o ponto de avaliação final toca o banco de dados.

A preguiça tem um custo bem conhecido, no entanto: acessar um campo de um objeto relacionado dentro de um loop (book.author.name para cada book em um queryset) dispara uma consulta por iteração, porque o objeto relacionado é ele próprio buscado preguiçosamente na primeira vez que é tocado - este é o clássico problema de consulta N+1, e ele existe especificamente porque a preguiça torna fácil escrever código que parece acesso a atributo simples, mas que emite silenciosamente uma consulta.

select_related (para ForeignKey/OneToOne, via um JOIN SQL) e prefetch_related (para ManyToMany/ForeignKey reverso, via uma segunda consulta e junção em Python) existem para colapsar esse padrão N+1 em uma ou duas consultas, mas eles precisam ser solicitados explicitamente - o Django não infere o padrão de acesso com antecedência.

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)
 
# Uma consulta total, não uma consulta por livro:
Book.objects.select_related("author").filter(author__name__startswith="A")

As Migrações seguem um modelo relacionado, mas distinto: o Django rastreia o estado de cada modelo a partir da última migração, e makemigrations gera um novo arquivo de migração comparando seu código de modelo atual com esse estado rastreado - ele não lê o esquema do banco de dados ativo para decidir o que mudou.

migrate então aplica os arquivos de migração pendentes no banco de dados real, na ordem de dependência registrada dentro de cada migração, que é por que as migrações são arquivos commitados no controle de versão em vez de uma etapa de sincronização automática em tempo de execução.

Considerações Avançadas e Aplicações

O ORM do Django foi projetado inicialmente para ser síncrono, e essa suposição ainda molda as views assíncronas: o Django adicionou suporte a views async def e implantação ASGI, mas os métodos de consulta do ORM permanecem em grande parte síncronos, de modo que uma view assíncrona que consulta o banco de dados precisa de ponte sync_to_async (ou um dos métodos ORM assíncronos mais recentes adicionados em lançamentos recentes) em vez de obter I/O assíncrono nativo gratuitamente.

Isso significa que "minha view é async def" não significa automaticamente "meu acesso ao banco de dados não é bloqueante" - veja Async Views & Channels para onde essa fronteira realmente se situa.

O site de administração é um benefício direto da introspecção da camada de modelo: admin.site.register(Model) funciona porque o Django pode ler os campos, relacionamentos e validadores de um modelo para gerar formulários CRUD sem nenhum código específico de administração, que é também por que o admin não é uma boa opção como interface pública - ele expõe exatamente a forma dos seus modelos, não uma interface curada.

O cache interage com ambas as metades deste modelo: o cache em nível de middleware (UpdateCacheMiddleware/FetchFromCacheMiddleware) envolve respostas inteiras usando a mesma mecânica de cebola descrita acima, enquanto o cache em nível de queryset se aplica apenas dentro do cache de resultados de um único QuerySet avaliado, não entre requisições - veja Caching & Performance.

Equívocos Comuns

• "MTV é apenas o nome do Django para MVC." O mapeamento não é um para um: o "Template" do Django desempenha o papel que o MVC chama de "view" (renderização), e a "View" do Django desempenha o papel que o MVC chama de "controller" (lógica de tratamento de requisições), o que é o oposto do que a palavra compartilhada "view" sugere.
• "Um QuerySet executa sua consulta assim que você a escreve." Ele não executa nenhum SQL até que algo force a avaliação - iteração, list(), fatiamento sem filtro adicional, ou uma verificação booleana/de comprimento - que é o que torna possível o encadeamento seguro de métodos em primeiro lugar.
• "Migrações mantêm o banco de dados sincronizado automaticamente." makemigrations apenas gera arquivos de migração comparando seu código de modelo atual com o estado do modelo rastreado pelo Django; alguém (ou uma etapa de implantação) ainda precisa executar migrate para que o banco de dados realmente mude.
• "A ordem do middleware em MIDDLEWARE mal importa." Como o middleware se aninha como uma cebola, as mudanças de ordem afetam tanto quando a lógica é executada na entrada quanto quando é executada na saída - middleware relacionado à segurança e sessão, em particular, dependem de ordenação estrita.
• "Views assíncronas tornam o acesso ao banco de dados do Django assíncrono." Funções de view podem ser async def, mas a maior parte da execução de consultas do ORM ainda é síncrona nos bastidores e precisa de ponte explícita para ser executada com segurança dentro de uma view assíncrona.

FAQs

Relacionados

• Django Basics - projetos, apps, URLs e views na prática
• Models & the ORM - campos, relacionamentos e padrões de queryset em profundidade
• Migrations - como os arquivos de migração são gerados e aplicados
• Caching & Performance - cache em nível de middleware e em nível de queryset
• Async Views & Channels - a fronteira ORM assíncrona/síncrona na prática
• Django REST Framework - uma camada de serialização construída sobre este mesmo ciclo de requisição

Versões da Stack: Esta página foi escrita para Django 5.2 em Python 3.14 (manutenção: 3.13).