Comparativo de montagens no Docker: guia para escolher Volume ou Bind Mount (com teste de desempenho)

Quando usei Docker pela primeira vez, a parte de montagem de dados foi a mais confusa. Certa vez, um contêiner do ambiente de testes reiniciou de repente. Atualizei a página e ela ficou em branco. Ao abrir o banco de dados, descobri que todos os dados tinham sumido. Só depois entendi que a perda de dados em reinicializações de contêiner não é brincadeira.

Talvez você já tenha passado por algo parecido:

• Digita -v no comando para montar um diretório, mas não faz ideia de onde os dados realmente ficam armazenados
• Executa npm install no Mac e ele demora tanto que você toma um café e, quando volta, ainda está rodando
• Vê alguém usando --mount type=volume, mas não entende qual é a diferença em relação a -v
• Não sabe quando usar Volume e quando usar Bind Mount

No fim, todos esses problemas vêm da falta de compreensão dos três tipos de montagem do Docker. Vamos comparar Volume, Bind Mount e tmpfs e entender em quais situações cada um deve ser usado. Com uma árvore de decisão e alguns cenários reais, você poderá escolher a montagem correta em apenas três minutos.

Fundamentos do gerenciamento de dados no Docker

Por que os dados somem quando o contêiner reinicia?

Comecemos por uma realidade incômoda: o contêiner em si não foi feito para armazenar dados.

Pense em um contêiner como uma embalagem descartável de comida. Quando você termina a refeição e joga a embalagem fora, qualquer resto que ficou dentro também vai embora. Com o contêiner é igual: ao removê-lo, os dados internos desaparecem junto. Mesmo sem removê-lo, apenas reiniciando, alguns dados também podem ser perdidos.

É por isso que precisamos de persistência de dados. Em termos simples, os dados importantes ficam fora do contêiner. Assim, os contêineres podem ir e vir enquanto os dados permanecem no lugar.

Qual é exatamente a diferença entre -v e --mount?

Sinceramente, quando comecei a usar Docker, esses dois parâmetros me davam dor de cabeça. Eles fazem praticamente a mesma coisa, mas a sintaxe é completamente diferente.

Por exemplo, para montar um volume no diretório /data do contêiner:

# Opção 1: usar -v (conciso, mas fácil de confundir)
docker run -v myvolume:/data nginx

# Opção 2: usar --mount (mais longo, mas claro)
docker run --mount type=volume,source=myvolume,target=/data nginx

Percebeu a diferença? Com -v, há apenas dois pontos: a origem fica à esquerda e o destino à direita. É simples, mas você não consegue identificar imediatamente se é um Volume ou um Bind Mount.

Com --mount é diferente. O comando informa claramente type=volume, indicando uma montagem Volume. Cada parâmetro aparece de forma explícita. Dá um pouco mais de trabalho para digitar, mas, ao rever o comando seis meses depois, você o entenderá de imediato.

Minha recomendação: use --mount em produção e -v em experimentos pessoais.

Esta tabela ajuda a comparar rapidamente:

[Imagem: comparação visual dos comandos]
Prompt: terminal screen showing docker run commands with -v and —mount side by side, modern tech style, blue and green colors, high quality

Comparativo detalhado dos três tipos de montagem

Agora vamos ao ponto principal. O Docker oferece três tipos de montagem: Volume, Bind Mount e tmpfs. Cada um tem suas particularidades. Usar o tipo certo evita problemas; escolher o errado pode criar uma bela dor de cabeça.

Volume: deixe o Docker cuidar de tudo

Volume é como contratar alguém para cuidar dos seus dados. Você pede para gerenciá-los, e o Docker os coloca em um local específico — no Linux, em /var/lib/docker/volumes/ — sem que você precise se preocupar com os detalhes.

Uma característica de que gosto muito no Volume é o desempenho consistente entre plataformas. Seja no Linux, no Mac ou no Windows, seu comportamento é praticamente o mesmo. Isso é muito importante para equipes, porque evita o constrangimento do famoso “na minha máquina funciona”.

O Volume também tem uma grande vantagem: pode ser gerenciado diretamente com comandos do Docker.

# Criar um Volume
docker volume create my-data

# Listar todos os Volumes
docker volume ls

# Ver detalhes do Volume (onde os dados estão armazenados)
docker volume inspect my-data

# Fazer backup do Volume (muito simples)
docker run --rm -v my-data:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data

Quando usar Volume?

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

• Em bancos de dados como MySQL e PostgreSQL, nos quais a segurança dos dados vem em primeiro lugar
• Para dados que precisam ser compartilhados por vários contêineres, como um diretório de upload de arquivos
• Para dados persistentes em produção, pois são fáceis de copiar e migrar

[Imagem: diagrama do funcionamento do Volume]
Prompt: Docker volume management diagram, Docker managing storage volumes, clean infographic style, blue and white colors, high quality

Bind Mount: você assume o controle

O Bind Mount funciona de outra forma. Ele monta diretamente um diretório do host dentro do contêiner. Em outras palavras, você escolhe qualquer local para a montagem e o Docker não o gerencia.

A principal vantagem é a sincronização em tempo real. Ao alterar o código local, a mudança aparece imediatamente no contêiner. Isso é ótimo no ambiente de desenvolvimento: você modifica o código, atualiza a página e já vê o resultado, sem reconstruir a imagem.

Mas o Bind Mount tem uma armadilha, especialmente para usuários de Mac e Windows.

Em um teste feito por Paolo Mainardi em 2025, o npm install no Mac ficou 3,5 vezes mais lento com Bind Mount do que com Volume. Por quê? O Docker Desktop no Mac usa virtualização. Cada acesso a um arquivo no Bind Mount precisa atravessar a fronteira da máquina virtual, o que gera um custo significativo.

# Exemplo de Bind Mount (monta o diretório atual no contêiner)
docker run -d \
  --name my-app \
  --mount type=bind,source=$(pwd),target=/app \
  node:18

# Ou com a sintaxe -v (o efeito é o mesmo)
docker run -d --name my-app -v $(pwd):/app node:18

Quando usar Bind Mount?

• No ambiente de desenvolvimento local, quando você precisa ver alterações no código em tempo real
• Para montar arquivos de configuração, como nginx.conf e .env
• Para enviar logs ao host e facilitar sua consulta

Quando não usar?

• No Mac e Windows, não monte diretórios de dependências como node_modules e vendor com Bind Mount, pois o desempenho será péssimo
• Use com cuidado em produção, pois a forte dependência de caminhos pode impedir a execução em outra máquina

tmpfs: um bloco de notas na memória

tmpfs é uma opção especial: armazena os dados na memória. Quando o contêiner para, todos eles desaparecem. Isso pode parecer pouco útil, mas em determinados cenários é excelente.

A leitura e a gravação em memória são dezenas ou até centenas de vezes mais rápidas do que no disco. Se os dados já são temporários, como cache do Redis, tokens temporários ou dados de sessão, por que não usar a opção de armazenamento mais rápida?

# Exemplo de tmpfs (cria um armazenamento de 100 MB na memória)
docker run -d \
  --name fast-cache \
  --mount type=tmpfs,target=/cache,tmpfs-size=100M \
  redis:7

Quando usar tmpfs?

• Para dados temporários em cache que não precisam ser persistidos
• Para armazenar temporariamente informações sensíveis, já que os dados na memória desaparecem quando a energia é desligada
• Em cenários com exigência extrema de desempenho, como análise de logs em tempo real

Atenção: tmpfs só pode ser usado em contêineres Linux. O Docker Desktop no Mac e Windows não oferece suporte.

Comparativo dos três tipos

Ao colocar os três tipos lado a lado, as diferenças ficam claras:

Depois dessa tabela, você já deve ter uma boa ideia de qual escolher.

Guia de escolha por cenário

Talvez você ainda esteja em dúvida: qual tipo devo usar no meu projeto?

Calma. Preparei uma árvore de decisão com apenas três perguntas:

Árvore de decisão rápida

Pergunta 1️⃣: os dados precisam ser persistidos?
  ├─ Não (cache, arquivos temporários) → Use tmpfs
  └─ Sim → Pergunta 2️⃣

Pergunta 2️⃣: é um ambiente de desenvolvimento ou produção?
  ├─ Produção → Use Volume
  └─ Desenvolvimento → Pergunta 3️⃣

Pergunta 3️⃣: os arquivos precisam ser alterados em tempo real, como o código?
  ├─ Sim → Bind Mount
  │   └─ Está no Mac/Windows? → Use Volume para dependências como node_modules
  └─ Não → Volume

Ainda parece um pouco abstrato? Sem problema. Veja como aplicar a decisão em alguns cenários reais.

Cenário 1: banco de dados MySQL

Em um banco de dados, perder os dados pode ser um desastre. Portanto, escolha Volume sem hesitar.

# Criar um contêiner MySQL (sintaxe recomendada)
docker run -d \
  --name mysql \
  --mount type=volume,source=mysql-data,target=/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  mysql:8.0

# Ver informações do Volume
docker volume inspect mysql-data

Por que usar Volume?

• ✅ Os dados ficam seguros e são gerenciados pelo Docker
• ✅ O backup é fácil e pode ser feito com um único comando
• ✅ O desempenho é consistente entre plataformas
• ✅ A migração para outro servidor é simples

[Imagem: armazenamento do MySQL em Volume]
Prompt: MySQL database with Docker volume storage, data persistence visualization, professional tech illustration, blue and orange colors, high quality

Cenário 2: ambiente de desenvolvimento Node.js no Mac

Este é um cenário clássico. Você desenvolve um projeto Node.js no Mac e quer ver as alterações no código em tempo real, mas não quer que o npm install demore uma eternidade. O que fazer?

Use uma solução híbrida: Bind Mount para o código e Volume para as dependências.

# Criar um contêiner de desenvolvimento Node.js
docker run -d \
  --name my-node-app \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=bind,source=$(pwd)/package.json,target=/app/package.json \
  --mount type=volume,source=node-modules-cache,target=/app/node_modules \
  -p 3000:3000 \
  node:18 \
  npm run dev

Veja o que acontece:

• O diretório src usa Bind Mount, então as alterações no código entram em vigor imediatamente
• package.json usa Bind Mount, então as mudanças nas dependências ficam visíveis
• node_modules usa Volume, evitando o problema de desempenho no Mac

Na primeira execução, instale as dependências:

# Entrar no contêiner e instalar as dependências
docker exec my-node-app npm install

Com isso, o npm install pode ficar mais de 3 vezes mais rápido. Em meu teste, a instalação que antes levava dois minutos caiu para apenas 40 segundos depois de trocar para Volume.

Cenário 3: arquivo de configuração do Nginx

Quem trabalha com operações certamente já passou por isto: você altera uma configuração do Nginx, reinicia o contêiner e a configuração desaparece. Como resolver?

Monte o arquivo de configuração com Bind Mount e adicione a opção readonly para aumentar a segurança.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

# Montar a configuração do Nginx (modo somente leitura)
docker run -d \
  --name nginx \
  --mount type=bind,source=$(pwd)/nginx.conf,target=/etc/nginx/nginx.conf,readonly \
  -p 80:80 \
  nginx:latest

# Recarregar após alterar a configuração (sem reiniciar o contêiner)
docker exec nginx nginx -s reload

Por que usar Bind Mount?

• ✅ As alterações no arquivo de configuração entram em vigor imediatamente
• ✅ O arquivo fica no host e é fácil de gerenciar
• ✅ O modo readonly impede que o contêiner altere a configuração

Cenário 4: cache temporário do Redis

O Redis é usado como cache, portanto seus dados já são temporários. Se eles forem perdidos, basta gerá-los novamente. Nesse cenário, tmpfs é a melhor opção.

# Usar tmpfs no Redis (desempenho máximo)
docker run -d \
  --name redis-cache \
  --mount type=tmpfs,target=/data,tmpfs-size=512M \
  -p 6379:6379 \
  redis:7 \
  redis-server --save ""

# Atenção: --save "" desativa a persistência RDB (os dados já estão na memória)

Por que usar tmpfs?

• ✅ A leitura e a gravação em memória são as mais rápidas
• ✅ Os dados de cache não precisam ser persistidos
• ✅ O conteúdo é apagado automaticamente quando o contêiner reinicia, de acordo com a semântica de cache

Cuidado: tmpfs só funciona em contêineres Linux. Ele não funciona no Docker Desktop do Mac.

Cenário 5: coleta de logs

Durante o desenvolvimento, você quer ver os logs do contêiner sem precisar executar docker logs toda vez. A solução é enviar os logs para o host.

# Montar o diretório de logs no host
docker run -d \
  --name my-app \
  --mount type=bind,source=$(pwd)/logs,target=/app/logs \
  my-app:latest

# Depois, acompanhar os logs em tempo real no host
tail -f logs/app.log

Assim, os arquivos de log ficam diretamente no ambiente local. Você pode abri-los no VS Code, pesquisar com grep ou enviá-los para uma plataforma de análise de logs.

Otimização de desempenho e armadilhas comuns

Depois dos cenários, vamos falar das armadilhas mais comuns. Passei por todas elas e, se você souber o que esperar, poderá economizar bastante tempo.

Armadilha 1: desempenho péssimo no Mac e Windows

Lembra do teste de Paolo Mainardi? No Mac, o Bind Mount foi 3,5 vezes mais lento do que o Volume. Não é uma diferença pequena: um npm install que levaria 40 segundos pode demorar dois minutos com Bind Mount.

Por que é tão lento?

No Mac e Windows, o Docker roda dentro de uma máquina virtual. Ao montar arquivos com Bind Mount, cada operação de leitura e gravação precisa atravessar a fronteira da máquina virtual. Esse custo é enorme, principalmente em diretórios como node_modules, que têm milhares de arquivos pequenos.

Como resolver:

# Opção 1: Volume para dependências e Bind Mount para o código (recomendado)
docker run -d \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=volume,source=deps,target=/app/node_modules \
  node:18

# Opção 2: se precisar usar Bind Mount, adicione :cached (somente no Docker Desktop)
docker run -d -v $(pwd):/app:cached node:18

O que é :cached? Ele informa ao Docker que os arquivos do host são a fonte autoritativa e que a sincronização dentro do contêiner pode atrasar. Isso reduz parte do custo de sincronização, embora o resultado não seja tão bom quanto usar Volume diretamente.

Armadilha 2: problemas de permissão, sem conseguir gravar arquivos no contêiner

Esse problema é muito comum. Você executa um contêiner e o programa retorna o erro “Permission denied”.

Causa: o UID do usuário no contêiner é diferente do UID no host.

Por exemplo, você é o usuário de UID 1000 no host e cria um diretório que será montado no contêiner. Dentro do contêiner, o programa pode rodar por padrão com UID 0, como root, ou UID 999, como algum usuário de serviço. Quando esses UIDs não correspondem, as permissões dos arquivos ficam inconsistentes.

Como resolver:

# Opção 1: executar o contêiner com seu UID
docker run --user $(id -u):$(id -g) \
  --mount type=bind,source=$(pwd),target=/app \
  node:18

# Opção 2: definir o usuário no Dockerfile
FROM node:18
RUN useradd -m -u 1000 appuser
USER appuser
WORKDIR /app

Normalmente uso a primeira opção, por ser mais simples e direta. A segunda é adequada para cenários nos quais você precisa empacotar a aplicação em uma imagem.

Armadilha 3: problemas de caminho no Windows

Usuários do Windows costumam ter problemas com a sintaxe dos caminhos. Um caminho no Windows usa o formato C:\Users\..., que pode causar erro quando escrito diretamente em um comando Docker.

Sintaxe correta:

# PowerShell (recomendado)
docker run -v ${PWD}:/app node:18

# CMD (prompt de comando clássico)
docker run -v %cd%:/app node:18

# Git Bash (ambiente semelhante ao Unix)
docker run -v /c/Users/yourname/project:/app node:18

# Ou use barras duplas
docker run -v //c/Users/yourname/project:/app node:18

Se ainda estiver em dúvida, use docker-compose, que trata automaticamente os problemas de caminho.

Armadilha 4: o acúmulo de Volumes enche o disco

Usar Volume é muito prático, mas há um problema: remover um contêiner não remove automaticamente o Volume. Com o tempo, o diretório /var/lib/docker/volumes/ pode ocupar todo o disco.

Faça limpezas periódicas:

# Listar todos os Volumes
docker volume ls

# Listar Volumes sem uso (órfãos)
docker volume ls -f dangling=true

# Limpar todos os Volumes sem uso (cuidado!)
docker volume prune

# Para uma limpeza mais completa, incluindo contêineres, imagens e redes
docker system prune -a --volumes

Tenho o hábito de executar docker volume prune uma vez por semana. Não faz sentido deixar Volumes de teste ocupando o disco.

Armadilha 5: onde ficam os dados do Volume e como fazer backup manual?

Muitas pessoas não sabem onde os dados do Volume são armazenados. É fácil descobrir:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

# Ver o caminho real do Volume
docker volume inspect my-data

# Procurar o campo "Mountpoint" na saída
# Normalmente é: /var/lib/docker/volumes/my-data/_data

Mesmo assim, não recomendo manipular diretamente os arquivos desse diretório, pois pode haver problemas de permissão. É mais seguro fazer o backup com comandos do Docker:

# Fazer backup do Volume em um arquivo tar
docker run --rm \
  -v my-data:/source \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/my-data-backup.tar.gz -C /source .

# Restaurar o backup em um novo Volume
docker run --rm \
  -v new-data:/target \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/my-data-backup.tar.gz -C /target

Já usei essa técnica para migrar bancos de dados em produção, e ela funciona muito bem.

[Imagem: fluxo de backup de um Volume]
Prompt: Docker volume backup workflow diagram, tar archive process, clean technical illustration, green and blue colors, high quality

Boas práticas com docker-compose

Até aqui, usamos comandos docker run. Em projetos reais, porém, é mais comum usar docker-compose. A seguir, há um exemplo completo com os três tipos de montagem.

Exemplo completo de docker-compose.yml

Esta é uma arquitetura típica de aplicação web: aplicação frontend em Node.js, API de backend, banco de dados PostgreSQL e cache Redis.

version: '3.8'

services:
  # Aplicação web (ambiente de desenvolvimento)
  web:
    image: node:18
    container_name: my-web-app
    working_dir: /app
    command: npm run dev
    ports:
      - "3000:3000"
    volumes:
      # Código-fonte: Bind Mount (alterações em tempo real)
      - type: bind
        source: ./src
        target: /app/src
      # package.json: Bind Mount (permite ver alterações nas dependências)
      - type: bind
        source: ./package.json
        target: /app/package.json
      # node_modules: Volume (evita o problema de desempenho no Mac)
      - type: volume
        source: node-modules
        target: /app/node_modules
    environment:
      - NODE_ENV=development
    depends_on:
      - db
      - cache

  # Banco de dados (configuração para produção)
  db:
    image: postgres:15
    container_name: postgres-db
    ports:
      - "5432:5432"
    volumes:
      # Dados: Volume (persistência e backup)
      - type: volume
        source: postgres-data
        target: /var/lib/postgresql/data
      # Script de inicialização: Bind Mount (somente leitura)
      - type: bind
        source: ./init.sql
        target: /docker-entrypoint-initdb.d/init.sql
        read_only: true
    environment:
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
      - POSTGRES_DB=mydb

  # Cache Redis (configuração de alto desempenho)
  cache:
    image: redis:7
    container_name: redis-cache
    ports:
      - "6379:6379"
    volumes:
      # Dados temporários: tmpfs (desempenho máximo, sem persistência)
      - type: tmpfs
        target: /data
        tmpfs:
          size: 100M  # Limitar o uso de memória
    command: redis-server --save ""  # Desativar a persistência RDB

  # Proxy reverso Nginx
  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      # Arquivo de configuração: Bind Mount (fácil de alterar, somente leitura)
      - type: bind
        source: ./nginx.conf
        target: /etc/nginx/nginx.conf
        read_only: true
      # Logs: Bind Mount (facilita a consulta)
      - type: bind
        source: ./logs/nginx
        target: /var/log/nginx
    depends_on:
      - web

# Declaração de volumes no nível superior (gerenciamento centralizado de todos os Volumes)
volumes:
  node-modules:
    driver: local
  postgres-data:
    driver: local
    # É possível definir driver_opts para configurar a estratégia de backup e outras opções

Explicação da configuração

Estratégia de montagem da aplicação web:

• O diretório src usa Bind Mount: ao alterar o código, a mudança entra em vigor imediatamente e o hot reload funciona muito bem
• node_modules usa Volume: essencial para usuários de Mac, pois evita a perda de desempenho
• package.json usa Bind Mount: depois de adicionar uma dependência, basta executar npm install dentro do contêiner

Estratégia de montagem do banco de dados:

• O diretório de dados usa Volume: persistência adequada para produção, gerenciada pelo Docker
• O script de inicialização usa Bind Mount com read_only: ele é executado apenas na primeira criação do banco e fica protegido contra alterações acidentais

Estratégia de montagem do Redis:

• Usa tmpfs: os dados de cache não precisam ser persistidos e a memória oferece o melhor desempenho
• Limita size: 100M: evita que o Redis consuma toda a memória

Estratégia de montagem do Nginx:

• O arquivo de configuração usa read_only: impede que o contêiner altere a configuração
• Os logs usam Bind Mount: você pode executar tail -f no host para acompanhá-los em tempo real

Comandos úteis

# Iniciar todos os serviços
docker-compose up -d

# Ver todos os Volumes
docker-compose exec web ls -la /app/node_modules  # Verificar as dependências

# Entrar no contêiner e instalar dependências (na primeira inicialização)
docker-compose exec web npm install

# Recarregar a configuração do Nginx (sem reiniciar o contêiner)
docker-compose exec nginx nginx -s reload

# Fazer backup do Volume do banco de dados
docker run --rm \
  -v blog-write-agent_postgres-data:/source \
  -v $(pwd):/backup \
  alpine tar czf /backup/db-backup.tar.gz -C /source .

# Parar e limpar (os Volumes não serão removidos)
docker-compose down

# Parar e remover os Volumes (cuidado com a perda de dados!)
docker-compose down -v

Otimizações específicas para usuários de Mac e Windows

Se você desenvolve no Mac ou Windows, a configuração acima já está otimizada. Mas ainda é possível melhorar:

# Adicione ao serviço web
volumes:
  - ./src:/app/src:cached  # Modo cached, reduz o custo de sincronização

:cached informa ao Docker que as atualizações nos arquivos do host têm prioridade e que a sincronização com o contêiner pode atrasar. Isso pode melhorar o desempenho entre 20% e 30%.

[Imagem: arquitetura do docker-compose]
Prompt: Docker compose multi-container architecture, web app database redis nginx, professional system diagram, blue and purple gradient, high quality

Conclusão

Depois de tudo isso, vamos recapitular.

Os três tipos de montagem do Docker são, no fim das contas, três ferramentas:

• Volume: deixe o Docker cuidar dos dados; é prático, estável e multiplataforma
• Bind Mount: gerencie os arquivos por conta própria; é flexível e funciona em tempo real, mas exige atenção ao desempenho
• tmpfs: é como um bloco de notas na memória; muito rápido e descartável

Lembre-se destas três regras para escolher:

1. Use Volume para dados de produção, como bancos de dados e arquivos persistentes
2. Use Bind Mount para código em desenvolvimento, com alterações em tempo real e hot reload
3. Use tmpfs para dados temporários, como cache e informações sensíveis

Atenção especial para usuários de Mac e Windows:

• Nunca monte diretórios de dependências como node_modules e vendor com Bind Mount. Com Volume, o processo pode ficar mais de 3 vezes mais rápido
• Se for realmente necessário usar Bind Mount, adicione a opção :cached

Como próximo passo, escolha um projeto que você esteja desenvolvendo e tente converter o comando docker run em um arquivo docker-compose.yml. Use Volume, Bind Mount e tmpfs, execute o projeto e compare as diferenças. Você perceberá que escolher a montagem correta melhora o desempenho e também deixa a estrutura do projeto mais clara.

Se tiver alguma dúvida, deixe um comentário. Também aprendi passando por vários problemas, e podemos aprender juntos.