DTOs sem complicação: entendendo por que eles existem
Leia. Curta. Comente. Compartilhe.
...
Entenda de forma simples por que nem todos os dados da sua Entity precisam entrar ou sair pela API e como os DTOs ajudam a organizar essa comunicação.
...
DTOs
Quando você começa a desenvolver APIs com Spring, é bem comum surgir uma dúvida:
“Se eu já tenho minha Entity, por que preciso criar um DTO com campos parecidos?”
Parece trabalho duplicado.
Só parece.
Imagine o cadastro de um hotel
O sistema de um hotel pode guardar várias informações sobre você:
Nome
CPF
Telefone
Endereço
Dados de pagamento
Número do quarto
Agora imagine que o hotel precisa mostrar seu nome em uma lista para o funcionário do café da manhã.
Precisa mandar tudo isso?
Claro que não.
Seria mais ou menos:
“Bom dia, seu nome está na lista. Aproveitando, aqui estão CPF, endereço e cartão.”
Socorro.
O funcionário precisa receber somente os dados necessários para aquela situação.
É exatamente essa ideia que ajuda a entender um DTO.
Entity e DTO não têm o mesmo trabalho
De forma bem simples:
Entity representa os dados que fazem parte da persistência da aplicação.
DTO (Data Transfer Object) representa os dados que queremos transportar entre partes do sistema, como na entrada ou saída de uma API.
Imagine uma Entity:
@Entity
public class Usuario {
private Long id;
private String nome;
private String email;
private String senha;
}
Será que uma resposta da API precisa devolver a senha?
Definitivamente não.
Podemos criar um DTO:
public record UsuarioResponse(
Long id,
String nome,
String email
) {}
Agora a resposta contém somente aquilo que queremos expor.
A Entity sabe mais. O DTO conta apenas o necessário.
DTO também ajuda na entrada
A mesma ideia vale quando alguém envia informações para sua API.
Para criar um usuário, talvez você precise:
public record CriarUsuarioRequest(
String nome,
String email,
String senha
) {}
Perceba que não existe id.
Faz sentido.
Quem cria o ID normalmente é a própria aplicação ou o banco. O usuário não precisa chegar dizendo:
“Olá, quero me cadastrar e decidi que meu ID será 847.”
Cada objeto recebe somente aquilo que faz sentido para aquela operação.
Request e Response ajudam a deixar tudo mais claro
Você pode encontrar nomes como:
UsuarioRequest
UsuarioResponse
CriarUsuarioRequest
AtualizarUsuarioRequest
Isso deixa explícito para que aquele DTO existe.
Um recebe informações.
Outro devolve informações.
Outro pode servir apenas para atualização.
Em vez de uma única classe tentando resolver todos os problemas da humanidade.
3 dicas para não complicar os DTOs
1. Não coloque um campo só porque ele existe na Entity
Pergunte:
Quem está recebendo esse DTO realmente precisa dessa informação?
Se não precisa, talvez o campo nem devesse estar ali.
2. Request e Response podem ser diferentes
O que entra na API não precisa ser exatamente igual ao que sai.
E normalmente não é.
3. Não crie DTO só por criar
DTO é uma ferramenta.
Se você criar quinze classes diferentes sem entender por quê, apenas trocou um problema por outro.
A ideia é separar responsabilidades, não colecionar arquivos Java.
No fim, DTO é sobre controlar a conversa
Sua Entity pode conhecer vários detalhes da aplicação.
Mas isso não significa que todos esses detalhes precisam viajar pela API.
O DTO funciona quase como alguém dizendo:
“Para essa conversa, você só precisa saber disso aqui.”
Quando você entende dessa forma, criar uma classe a mais deixa de parecer trabalho duplicado.
Passa a ser uma forma de controlar melhor o que entra, o que sai e o que cada parte da aplicação realmente precisa conhecer.
>>> Quando você conheceu DTOs, também pensou: “mas eu já não tenho uma Entity para isso?”
___
Indicação de livro
Spring Start Here
Autor: Laurentiu Spilca
É uma boa opção para entender melhor como aplicações Spring são estruturadas e como as diferentes partes de uma API trabalham juntas, sem começar por conteúdos absurdamente avançados.
