Introdução
E aí pessoas, tudo bem?
Esse será o primeiro artigo do #Descomplica, uma série de pequenos artigos que irão sempre focar em um tema específico, com uma abordagem simples e direta sobre o assunto e o nosso primeiro assunto será sobre DTOs.
O que é um DTO
DTO (Data Transfer Object/Objeto de Transferência de Dados) é um(a) Design Pattern/Padrão de Projeto simples, porém eficiente para se aplicar na arquitetura um software.
Um DTO nada mais é que um objeto utilizado para encapsular e mapear dados primitivos e que podem ser serializados.
Como criar e utilizar um DTO
Como dito anteriormente, um DTO nada mais é que um objeto simples para encapsular e mapear dados que serão enviados entre as camadas da nossa aplicação. Então vamos ver um exemplo bem simples em PHP de um DTO utilizado para encapsular dados para um endpoint/serviço que irá salvar um usuário:
class SaveUserDTO
{
public function __construct(
private string $name,
private string $email,
private string $password
) {}
// GETTERS AND SETTERS
}
$userDTO = new SaveUserDTO('Wendell', 'me@wendelladriel.com', 'S3cR3t');
Como podem ver acima, criar e utilizar um DTO é extremamente simples e fácil. Agora vamos aprender o porquê utilizar esse padrão.
Porquê utilizar DTOs
Para mim, a utilização de DTOs no código gera um código simples, limpo e de fácil manutenção. Para quem trabalha com Laravel e outros frameworks PHP já devem ter visto como eu vi em várias aplicações algo como abaixo nos controllers:
public function saveUser(Request $request): JsonResponse
{
$this->service->saveUser($request->all());
}
No código acima o código pega todos os parâmetros do Request e os envia para a Camada de Serviço. Alguns dos problemas criados por isso são:
- Não temos a definição de quais valores estão a ser enviados
- Caso o Request seja atualizado, não vamos saber de forma fácil o que foi alterado
- Para alguém que não conhece o código ou se ficar um tempo sem mexer no código, dificilmente saberá os possíveis valores desse Request
Se ao invés de fazer isso, usarmos o DTO que criamos acima, qualquer dev que entrar na equipe ou caso alguém precise fazer alguma alteração ou manutenção no código, será muito mais fácil de saber quais são os dados esperados pelo serviço, o que podemos utilizar e como alterar algo se necessário.
O código fica muito mais limpo, fica muito mais fácil de dar manutenção ou alterar algo e oferece uma excelente DX (Developer Experience/Experiência para o Desenvolvedor) para toda a equipe!
Conclusão
Vimos nesse artigo o que é, como utilizar e o porquê utilizar DTOs para melhorar a arquitetura da nossa aplicação! Espero que tenham gostado e aproveitem pra comentar aqui se conheciam esse padrão, se utilizam e como utilizam!
Um grande abraço e até o próximo #Descomplica!
Oldest comments (4)
Gostei do artigo, mano. Consegui entender um poucos mais de Dto. Como tu explicaria a diferença de uma entidade pra um dto? E sobre dto, pode conter algum tipo de validação ou nao?
Entidade para mim é como um mapeamento de uma tabela da base de dados. Seria algo concreto da tua camada de dados enquanto o DTO é apenas um objeto que mapeia valores que podem ser relacionados com uma ou diversas entidades dependendo do contexto para execução de ações na aplicação! Um DTO de forma "pura" é para transportar dados de uma camada para outra, validação dos dados deve ser feita antes de colocar os dados no DTO para separar as responsabilidades!
Opa. Obrigado por responder. Acho muito complexo essas coisas ainda, mas ta mais claro agora pra mim com a tu resposta.
Foi mal pela demora. Novamente, ótimo artigo.
Que isso, sem problemas, eu também demorei a responder!
Fico feliz que tenha ajudado um pouco e que tenha gostado do artigo!