Skip to main content


Introdução ao Django​

O Django é um framework web escrito em Python, criado para facilitar o desenvolvimento de aplicações web robustas, seguras e escaláveis. Ele segue a filosofia de "baterias incluídas", ou seja, já vem com quase tudo o que você precisa para criar uma aplicação completa, sem depender de dezenas de bibliotecas externas.


O Django é muito usado para construir sistemas como painéis administrativos, APIs, portais, sistemas internos, plataformas educacionais e aplicações web em geral.



Framework Web​

Um framework web é um conjunto de ferramentas, bibliotecas e padrões que resolvem problemas comuns no desenvolvimento web, como o roteamento de URLs, processamento de requisições HTTP, acesso a banco de dados, autenticação de usuários e etc.


Em vez de começar tudo do zero, você usa essas estruturas prontas e foca na lógica do seu sistema.



Arquitetura do Django​

O Django usa o padrão a arquitetura MVT (Model, View, Template).

  • Model

    Representa os dados da aplicação. Cada model normalmente vira uma tabela no banco de dados.

  • View

    Contém a lógica da aplicação. Recebe a requisição HTTP, processa dados e devolve uma resposta.

  • Template

    É a camada de apresentação. Define como o HTML será exibido para o usuário.



Subindo ambientes para trabalhar com Django​

Vou criar um ambiente virtual para essa tarefa:

# Crie um ambiente virtual:
python3 -m venv django

# Entre no ambiente virtual:
cd django

# Ative o ambiente virtual:
source bin/activate

# Atualize o pip:
pip install pip --upgrade

# Instale o django:
pip install django

Agora vamos criar um projeto e executar esse projeto com a configuração padrão.

# Iniciando um projeto
django-admin startproject myproject .

# Executar um projeto django:
python manage.py runserver

manage.py

O manage.py serve para interagir com o projeto Django via linha de comando, sem precisar escrever código manualmente para tarefas comuns, ou seja, ele é a forma que usamos para controlar o projeto Django.


Os comandos mais comuns que usamos com o manage.py são:

# Sobe o servidor de desenvolvimento do Django para testes locais:
python manage.py runserver

# Cria a estrutura básica de um app Django:
python manage.py startapp blog

# Gera os arquivos de migration com base nas mudanças nos models (não altera o banco):
python manage.py makemigrations

# Aplica as migrations no banco de dados:
python manage.py migrate

# Cria um usuário administrador para acessar o '/admin':
python manage.py createsuperuser

# Abrir um shell com Django carregado:
python manage.py shell

# Executa os testes do projeto usando um banco temporário:
python manage.py test

Além do manage.py existe o comando django-admin, e os dois estão diretamente relacionados. O django-admin é a ferramenta global de administração do Django.


Ambos django-admin e manage.py fazem a mesma coisa. Mas para você ter o manage.py é preciso primeiro usar o django-admin para criar o projeto.


Portanto, o manage.py internamente chama o django-admin já configurado para o seu projeto.



Arquivo de Settings​

O settings.py, localizado dentro do diretório do projeto, é o arquivo central de configuração de um projeto Django, é nele que definimos como o projeto vai se comportar.


Esse script vai controlar quais apps existem no projeto, configuração com banco de dados, parte de segurança, autenticação, arquivos estáticos, comportamento de debug e produção e muitas outras configurações.


Abaixo podemos conferir algumas das principais configurações.

  • INSTALLED_APPS

    Lista de apps ativos no projeto, ou seja, quais partes do sistema o Django deve carregar e usar quando ele iniciar. Em Django, um projeto é apenas um contêiner, quem realmente entrega funcionalidades são os apps.

    INSTALLED_APPS = [
        'django.contrib.admin',
        'blog',
    ]

  • DATABASES

    Define a configuração com o banco de dados. A configuração abaixo não é a padrão e sim uma configuração um pouco mais customizada.

    DJANGO_DATABASE = getenv("DJANGO_DATABASE", "default")

    DATABASES_SETTINGS = {
      "dev": {
          "ENGINE": "django.db.backends.sqlite3",
          "NAME": f"{DB_NAME}.sqlite3",
      },
      "default": {
          "ENGINE": "django.db.backends.postgresql_psycopg2",
          "NAME": DB_NAME,
          "USER": DB_USER,
          "PASSWORD": DB_PASSWORD,
          "HOST": DB_HOST,
          "PORT": DB_PORT,
      },
    }

    DATABASE = DJANGO_DATABASE
    DATABASES = {"default": DATABASES_SETTINGS[DATABASE]}

  • DEBUG

    Controla modo desenvolvimento ou produção. Nunca usar True em produção.

    DEBUG = True

  • ALLOWED_HOSTS

    Quais hosts podem acessar o sistema.

    ALLOWED_HOSTS = ['meusite.com']

  • MIDDLEWARE

    Lista de camadas que processam cada requisição.

    MIDDLEWARE = [
        'django.middleware.security.SecurityMiddleware',
    ]

  • TEMPLATES

    Configuração de HTML e renderização de páginas.

    TEMPLATES = [
        {
            'BACKEND': 'django.template.backends.django.DjangoTemplates',
            'DIRS': [],
            'APP_DIRS': True,
            'OPTIONS': {
                'context_processors': [
                    'django.template.context_processors.request',
                    'django.contrib.auth.context_processors.auth',
                    'django.contrib.messages.context_processors.messages',
                ],
            },
        },
    ]

  • STATIC_URL

    Arquivos estáticos (CSS, JS).

    STATIC_URL = 'static/'

  • SECRET_KEY

    Chave usada para criptografia e segurança. Ela é usada internamente para assinar e validar dados sensíveis como: assinar cookies de sessão, garantir que o usuário não adulterou dados enviados pelo navegador, gerar e validar tokens de segurança (como tokens de CSRF, reset de senha e confirmações), assinar dados internos do framework, evita que informações críticas sejam falsificadas e muitas outras validações.

    Nunca divulgue essa chave em repositório público. Para gerar uma chave faça:

    python - << 'EOF'
    from django.core.management.utils import get_random_secret_key
    print(get_random_secret_key())
    EOF


Arquivo de urls​

O arquivo urls.py define como as URLs do sistema são mapeadas para o código que responde às requisições, ou seja, ele informa ao Django o que executar quando alguém acessa uma URL.


O urls.py funciona como um roteador. Ele não contém lógica de negócio, apenas decisões de caminho. Normalmente temos um urls.py principal no projeto, que é responsável por reunir tudo e um urls.py nos apps, que é responsável pelas rotas daquele app.


O arquivo principal geralmente inclui os URLs dos apps, mantendo tudo organizado.



Apps​

No Django, um app é onde vamos realmente criar o site. Cada App vai ter sua view, urls, interação com banco de dados e etc. O projeto serve apenas para organizar tudo, mas são os Apps quem realmente faz o trabalho de verdade.


É comum usar apps separados quando as responsabilidades são diferentes, exemplo:

  • Um app para autenticação e usuários
  • Outro app para posts ou conteúdo
  • Outro app para API

Como cada app cuida apenas do seu contexto, isso facilita manutenção, testes e reuso de código. Apesar disso, na prática do dia a dia, principalmente em projetos pequenos ou médios, é muito comum usar um único app.


Vamos criar nosso primeiro app:

python manage.py startapp home


Arquivo admin.py​

O arquivo admin.py serve para registrar e configurar como os dados do app aparecem no Django Admin. O Django Admin é uma interface pronta para gerenciar dados do banco, mas nenhum model aparece lá automaticamente.


O admin.py é o arquivo onde você diz ao Django quais models podem ser administrados pela interface web. Quando registramos um model no admin.py ele passa a aparecer no /admin e com isso poderá ser criado, editado e removido pela interface. Ele também segue regras de permissões do Django.


Sem registro, o model existe no banco, mas não aparece no admin. Além de simplesmente registrar models para que apareçam no Django Admin, o admin.py é o ponto onde se define como a interface administrativa se comporta para aquele app. Ele funciona como uma camada de adaptação entre os dados do banco e a forma como esses dados são apresentados e manipulados pela interface web.


Quando um model é exposto no admin sem nenhuma configuração adicional, o Django oferece uma visualização genérica, suficiente para operações básicas, mas limitada. O admin.py existe justamente para permitir que essa interface seja ajustada à realidade do sistema. É nele que se define quais informações são mais relevantes para quem administra o sistema, como os dados devem ser exibidos e quais ações podem ser realizadas com segurança.



Arquivo apps.py​

O arquivo apps.py define a identidade e o ciclo de vida do app dentro do projeto. Ele é o ponto onde o Django passa a reconhecer formalmente aquele app como uma unidade do sistema.


Esse arquivo contém uma classe que descreve o app para o framework. Nela ficam informações como o nome do app, um identificador legível e, principalmente, o momento em que o app é carregado durante a inicialização do Django. Quando o projeto sobe, o Django percorre os apps listados em INSTALLED_APPS e, para cada um deles, carrega a configuração definida no apps.py.


O papel mais importante do apps.py não é a configuração estática, mas o controle de inicialização. É nele que se define código que deve ser executado quando o app fica pronto para uso, depois que o Django já carregou o sistema de modelos, conexões e dependências. Isso torna o apps.py o local adequado para inicializar integrações internas, registrar sinais e preparar comportamentos que precisam existir desde o início da aplicação.


Apesar disso, em projetos simples, o apps.py costuma passar quase despercebido, pois o comportamento padrão já é suficiente.



Arquivo models.py​

O arquivo models.py é onde se define a estrutura dos dados do sistema. Ele descreve como as informações são organizadas, armazenadas e relacionadas dentro do banco de dados, usando a linguagem do próprio Django.


No Django, você não cria tabelas escrevendo SQL diretamente. Em vez disso, você define models, que são classes Python que representam entidades do domínio da aplicação. Cada model corresponde a uma tabela no banco, e cada atributo do model representa uma coluna. A partir dessas definições, o Django consegue criar, alterar e manter o esquema do banco de forma automática por meio das migrations.


Mais do que uma simples definição de campos, o models.py expressa regras do negócio. Relações entre entidades, obrigatoriedade de dados, valores padrão e comportamentos associados aos registros são definidos ali. Isso faz com que o model seja o ponto central da consistência dos dados, independentemente de como eles são acessados, seja pelo admin, por views ou por APIs.


Os models também são a base do ORM do Django. É através deles que o código interage com o banco de dados de forma abstrata, sem depender diretamente do tipo de banco utilizado. Consultas, filtros, ordenações e relacionamentos são construídos a partir dos models, mantendo o código mais legível e portável.


Em termos de arquitetura, o models.py representa a camada de dados do sistema. Ele não cuida de interface, nem de rotas ou apresentação. Seu papel é definir o que o sistema armazena e quais garantias esses dados possuem. Por isso, alterações nesse arquivo costumam ser sensíveis e sempre caminham junto com migrations, pois impactam diretamente a estrutura do banco.



Arquivo tests.py​

O arquivo tests.py é o arquivo onde se define como o sistema deve se comportar de forma verificável. Ele existe para garantir que o código faça o que se espera, hoje e no futuro, mesmo depois de mudanças.


No Django, testes não são apenas uma etapa opcional. Eles fazem parte da forma como o framework foi pensado. O tests.py permite escrever cenários que simulam o uso real da aplicação e verificam se os resultados continuam corretos. Isso inclui regras de negócio, comportamento dos models, respostas das views e integração entre diferentes partes do sistema.


Quando os testes são executados, o Django cria um ambiente isolado, com um banco de dados temporário. Esse banco é montado a partir dos models e migrations e destruído ao final da execução. Isso garante que os testes não afetem dados reais e possam ser executados repetidamente sem efeitos colaterais.


O tests.py também funciona como documentação viva. Ao ler os testes, é possível entender quais comportamentos são esperados do sistema, quais casos são considerados válidos e quais situações devem ser rejeitadas. Em projetos maiores, os testes acabam sendo uma das fontes mais confiáveis de entendimento do domínio.


Embora o Django permita organizar testes em múltiplos arquivos e pastas, o tests.py representa o ponto inicial dessa prática dentro de cada app. Ele reforça a ideia de que cada app é responsável não apenas por sua funcionalidade, mas também por provar que essa funcionalidade funciona corretamente.



Arquivo views.py​

O arquivo views.py é onde a aplicação responde às requisições. Ele é o ponto em que uma URL se transforma em alguma ação concreta do sistema, seja exibir uma página, retornar dados ou executar uma regra de negócio.


No Django, uma view representa a lógica que decide o que fazer quando uma requisição chega. Ela recebe informações da requisição, como parâmetros, dados enviados pelo usuário e contexto de autenticação, e retorna uma resposta. Essa resposta pode ser uma página HTML, um JSON, um redirecionamento ou qualquer outro tipo de retorno HTTP.


O views.py atua como uma camada intermediária. Ele não define como os dados são armazenados, nem como as URLs são organizadas. Em vez disso, ele coordena o uso dos models, aplica regras do sistema e escolhe como o resultado deve ser apresentado. Por isso, é comum que uma view consulte models, valide informações e delegue a renderização para templates.


Um ponto importante é que as views não devem concentrar toda a complexidade do sistema. Quando a lógica cresce demais, ela costuma ser extraída para outras camadas, mantendo o views.py focado em orquestrar o fluxo da requisição. Essa separação ajuda a manter o código mais claro e testável.