Spring Data Rest e os DTOs
17/07/2017 01:43
5
Boa noite pessoal, quero levantar uma discussão aqui, o que vocês acham sobre o spring data rest e sobre a API acessar direto a sua entidade? Vocês usam DTOs ou classes de Request/Response?
Tags: spring, spring-data, spring-data-rest


1
Sem sombra de dúvidas é um risco pelos seguintes fatores:

1) dado que uma api deve prover mais que uma integração, informações acerca do negócio, você pode estar vazando detalhes sobre a camada inferior (já vi, por exemplo, casos em que a pessoa retornava acidentalmente até mesmo a senha do usuário nesta momento, isto sem mencionar toda a cadeia de relacionamentos)

2) e diretamente relacionado com o ponto acima. Sou a favor do API First. Com isto, projetando bons contatos, mesmo que a camada inferior seja um lixo, pelo menos consigo trocar no futuro (ao menos terei esta possibilidade). 

3) DTOs me ajudam a implementar o API First mais falso e, numa boa? Eles não precisam ser estúpidos. Podem ter, por exemplo construtores que recebem o domínio como valor ou mesmo métodos que me construam o domínio a partir dos dados armazenados.

Sendo assim, sou radicalmente contra o uso de classes de domínio boa contratos em qualquer plataforma, não só o Spring Boot.

Indo um pouco além, sou a favor de uma classe de facade para os controladores, assim os mantenho o mais simples que conseguir, evitando o vazamento de regras de negócio para esta camada também.


0
Bom eu pensava dessa forma também, mas mudei um pouco ao longo de algumas experiências.

1 - Existem hoje outras maneiras de esconder o que não precisa ser exibido utilizando Jackson ou qualquer outra lib JSON.

2 - Usando DDD você acaba tendo os Aggregates e isso facilita e muito na não quebra de conceito do seu domínio de negócio,  o maior problema aqui é que as pessoas vão relacionando tudo com tudo nos bancos de dados o que vira uma coisa difícil de se entender e expor. Então não quebrar o conceito e ter um domínio coeso faz com que você consiga expor ele sem problemas.

3 - Na sua maioria dos DTOs são uma cópia do objeto da base de dados, e em muitas vezes as pessoas usam frameworks para automatizar esse mapeamento o que pra mim não faz o menor sentido. Então acho que você deve usar onde tem que usar e onde não é preciso simplesmente não use.

4 - Se você realmente usar DDD e pensar mais em eventos do que fazer um PUT com um monte de campos para atualizar as coisas ficam mais simples e você não terá problemas, você muda o estado e não fica mais enviando e recebendo um monte de coisa do backend.

Acho que basicamente é isso, mas cada caso é um casa e cada um sabe melhor da situação do seu projeto e o que usar. Na minha opinião escrever código desnecessário é ruim e o dev acaba não dando devida atenção a isso e pode causar erros grandes.
18/07/2017 10:40


0
Oi Felipe, estes são excelentes pontos.
Na realidade, eu acabei seguindo o caminho oposto ao seu. No Grails, o modo de se desenvolver APIs é exatamente este que você está expondo. É sem sombra de dúvidas o caminho mais produtivo, não resta dúvidas a respeito disto. E realmente o ponto de se ocultar o que será retornado é também muito, muito válido (basta usar as anotações do Jackson).

Entretanto, é curioso, por que conforme fomos pegando cada vez mais projetos em Spring Boot (ainda não usei o Spring Data REST, talvez daí as minhas impressões), o caminho contrário, voltado para o uso de DTOs foi se mostrando mais seguro: era muito fácil via classe de domínio irmos, acidentalmente, desrespeitando contratos pré-determinados. Acabou que o uso dos DTOs nos disciplinou no cumprimento dos contratos que determinávamos. 

Curioso ainda é que recentemente começamos a trabalhar com .net e, no processo de aprendizado, observamos que o pessoal .net também é muito focado em DTOs na implementação de APIs. Mas no caso do .net estamos dando nossos primeiros passos ainda, então não posso dizer muita coisa.


0
Nos projetos onde trabalhei sempre foi utilizado o esquema de DTO, mas me questiono as vezes se isso não pode onerar a aplicação, visto que rola converters para todos os lados (tanto usando builder como o ObjectMapper do jackson).
19/07/2017 21:22


0
Acredito que no Spring Data Rest não é necessário o DTO, caso você precise modificar como a API é exposta você pode utilizar projeções? que acredito ser menos acoplado e mais simples.



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails, Spring e mais com a Formação itexto!

Livro de Spring


/dev/All

Os melhores blogs de TI
em um único lugar!

 
Spring Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.