Expondo modelos de domínio por API

8

Estou criando uma API RESTful simples para um aplicativo baseado na Web em que estou trabalhando e estou pensando sobre a melhor maneira de expor meus modelos de domínio.

Digamos que eu tenho uma classe User e desejo fornecer uma resposta JSON com as várias propriedades do usuário. Obviamente, não quero expor publicamente todas as propriedades do meu modelo (coisas como DateCreated, PasswordHash etc.) devido a problemas de segurança e largura de banda.

Eu li em Data Transfer Objects e estou me perguntando se esse é o caminho a percorrer. Se eu estiver certo, posso passar, por exemplo, um modelo de usuário para o meu DTO do usuário e garantir que o referido DTO permita apenas a exposição das propriedades do usuário que eu escolher (o que também ajudaria a desacoplar meus modelos da minha API pública).

Esta solução é apropriada ou existem maneiras melhores de fazer isso?

Obrigado.

language-agnostic api domain-model

— James
fonte

1

"Estou criando uma API pública simples " e "Obviamente, não quero expor publicamente todas as propriedades" não fazem sentido para mim, você poderia esclarecer o que quer dizer?

— Uooo 24/09

Editei minha pergunta para fornecer mais clareza, mas basicamente o que quero dizer é que meu objeto Usuário possui algumas propriedades como Senha e DateCreated que não devem ser mostradas na representação JSON do Usuário, mas na maioria dos outros dados do usuário. deve estar disponível. Gostaria de saber se os DTOs podem me ajudar a separar as propriedades disponíveis das indisponíveis.

— James

6

Essa é exatamente uma das razões pelas quais os DTOs existem.

A desvantagem aqui é que a adição de DTOs torna sua implementação um pouco mais complexa e, portanto, propensa a erros - como uma incompatibilidade no mapeamento do objeto de domínio para um DTO. Use testes de unidade para isso!

Outra coisa que você pode fazer com o seu DTO e tende a ser altamente esquecido nos serviços RESTful é tratar os dados de hipertexto para referências, objetos aninhados e possíveis operações.

Consulte o PoEAA de Martin Fowler: "[...] vale a pena mencionar que outra vantagem é encapsular o mecanismo de serialização para transferir dados através da conexão. Ao encapsular a serialização assim, os DTOs mantêm essa lógica fora do restante do código. e também forneça um ponto claro para alterar a serialização, se desejar ".

http://martinfowler.com/eaaCatalog/dataTransferObject.html

TL; DR: Gosto da ideia de separar as preocupações da lógica do domínio e da "fiação RESTful" através do DTOS, embora introduzindo um design mais complexo.

— viniciushana
fonte

1

Eu pensei isso, mas só queria esclarecer isso! Pelo menos para a minha situação, acho que os benefícios superam os contras. Obrigado pela sua resposta!

— James

supondo que seu código de back-end seja fortemente digitado, a complexidade incorrida é pesada pela verificação do tipo de tempo de compilação. Os mapeamentos dto.setProp (entity.getProp) começarão a falhar na compilação.

— Jason

3

Embora não seja o objetivo principal dos Objetos de Transferência de Dados , os DTOs podem ser usados para satisfazer essa preocupação de maneira semelhante à porção de dados de um Modelo de Apresentação .

Como foi apontado, isso pode inchar o seu design e algo tão simples quanto um campo adicionado pode exigir alterações para aparecer nas camadas adicionais. Por esse motivo , é aconselhável verificar se você pode fornecer metadados para descrever a serialização do objeto . Em muitos idiomas, isso toma a forma de anotações especializadas que podem ser aplicadas aos objetos do seu domínio para evitar a tradução tediosa para DTOs. Pacotes como Jackson ( através do uso de Mixins ) geralmente levam essa idéia um pouco mais longe para separar completamente seus metadados do modelo de domínio.

— smp7d
fonte