Durante a construção de um sistema em java é comum dividirmos nossa aplicação num modelo que chamamos de camadas, o grande “barato” desse modelo é a possibilidade de separarmos componentes de acordo com as suas responsabilidades.

Muitos desenvolvedores principalmente a galera que tá começando agora acha bobagem isso(é só mais um processo burocrático que a galera do Java inventou), mas se formos pensar em grandes projetos de software onde há uma grande quantidade de desenvolvedores atuando em torno do mesmo projeto, não arquitetar o sistema em camadas pode implicar em códigos ilegíveis e confusos, dificultando e muito a vida de novos devs que venham no futuro a dar manutenção no sistema em questão.

Exemplificando

Vamos supor que tenhamos a seguinte arquitetura de camadas no nosso projeto:

• No Item 1 temos a nossa aplicação web se comunicando com o nosso controller por meio de chamadas Http passando objetos JSON;

• No Item 2 temos o nosso controller(que é componente responsável pelas interações com a camada web), recebendo as solicitações vindas da web e chamando o service passando um objeto do tipo DTO (ja vamos falar dele mais abaixo).

• No Item 3 o nosso service(que é o componente responsável em executar as partes lógicas e regras de negócio da nossa aplicação) pega esse objeto DTO transforma para o padrão entidade mais popularmente conhecido como ORM(Mapeamento Objeto Relacional) e passa esse objeto que ele acabou de converter para o repository.

• No Item 4 o repository( que é a camada responsável pelo acesso a dados) vai até o Banco de Dados e executa a consulta.

Reparem que após a execução da consulta no banco o repository retorna o objeto ORM para a camada service, esse por sua vez transforma novamente para o padrão DTO e devolve esse DTO para a camada controller e esse por sua vez devolve novo DTO obtido para camada web.

Mas Afinal o que é esse tal DTO que tanto foi falado acima?

O DTO(Data Transfer Object) como o próprio nome já diz é um padrão de projeto onde tem como intuito transferir dados de um local para o outro da aplicação sem nenhum tipo de regra de negócio embutida no meio,possibilitando assim que façamos uma ordenação dos dados antes de exibirmos na nossa aplicação e uma diminuição no tráfego de rede,já que não há mais necessidade de retornar uma entidade com uma paulada de atributos.

Vamos supor que tenhamos na nossa aplicação a seguinte classe:

Repare que a minha classe User eu possuo algumas informações sigilosas como password e id(que é a forma como a informação é armazenada no banco de dados), por questões de segurança não gostaríamos de exibir essas informações através de um serviço rest. Se optarmos por utilizar diretamente essa classe User no retorno dos nossos métodos dentro da nossa classe controller iremos expor essas informações e não é isso que queremos,para resolver esse problema podemos criar uma classe chamada UsuarioDTO e ao invés de retornar nos nossos métodos todos os atributos da entidade vamos retornar o DTO com os atributos que queremos isto é “omitimos” as informações que queremos exibir, conforme podemos vê no exemplo abaixo:

Repare que no código acima e estou definindo que o meu UsuarioDTO só vai ter os atributos nome e email os demais eu estou "omitindo".

Um outro ponto a se observar no código acima é que utilizamos um método construtor que tem a finalidade de converter uma entidade no nosso caso User em um objeto do tipo DTO que no nosso caso se chamará UsuarioDTO.

Portanto toda vez que a nossa camada service estiver devolvendo dados para o controller precisaremos chamar este construtor conforme podemos ver no exemplo abaixo:

Caso queiramos fazer o inverso isto é converter de DTO para entidade poderíamos criar um método privado dentro da classe UserService onde faríamos essa conversão conforme podemos ver no exemplo abaixo:

Lembrando que esta é apenas uma das formas que a galera usa para fazer conversão de DTOs para entidades e vice e versa, existem algumas ferramentas com modelmapper que facilita a vida nesse processo de conversão.

Considerações Finais

A ideia deste artigo foi mostrar aos leitores a idéia central acerca do padrão de projeto DTO, mostrando sua real utilidade na forma como podemos proteger dados sensíveis, além de mostrar a você leitor o real ganho de qualidade e de organização de código quando adotamos uma arquitetura baseada em camadas.