Spring Data Rest e os DTOs
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
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.
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.
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.
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).
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.