Bom dia, estou trabalhando com uma arquitetura onde existe uma classe DTO e uma VO, as duas são idênticas o que difere é as anotações jpa do hibernate, na DTO não existe qualquer anotação e a VO é onde esta todas as anotações, o DTO é usado para “trafegar” entre as camadas do projeto ate a classe ModelFactory onde la eu tenho que converter o DTO para VO e assim enviar para o DAO e fazer algo.
Isso é uma boa separas a classe sem mapeamento para trafegar entre as camadas e depois transformar ela para poder persistir no BD?
Você vai ter todo tipo de resposta, de “sim” até “jamais”.
Eu digo que vai da tua escolha.
douglascst90
Gostaria de saber se alguem usa ou ja usou isso, se realmente pode trazer beneficios e/ou desvantagens.
Acredito que possa ser uma boa pratica pois nao estarei transportando um objeto “pesado” com as anotações jpa, estarei trabalhando somente com objetos simples e sem anotações.
drsmachado
douglascst90:
Gostaria de saber se alguem usa ou ja usou isso, se realmente pode trazer beneficios e/ou desvantagens.
Acredito que possa ser uma boa pratica pois nao estarei transportando um objeto “pesado” com as anotações jpa, estarei trabalhando somente com objetos simples e sem anotações.
Trabalho num sistema baseado em DTO e Grid, em que ora um, ora outro fazem esse papel. Além deles, tenho os beans, que são mapeados pelo hibernate (versão 2.0 o.O).
O primeiro projeto em que trabalhei com java possuía DTO, VO e helpers (os VOs da camada view).
Agora, não entendi o que você quis dizer com ‘pois não estarei transportando um objeto “pesado” com as anotações jpa’. Com ou sem anotação, o objeto e seus atributos terão o mesmo tamanho e sempre precisará passar entre as camadas, seja através de DTO ou o próprio VO ou mesmo cada um dos atributos em separado (acredite, já vi isso).
viniciusjssouza
Acho o DTO uma opção válida em arquiteturas Domain Driven, onde as entidades possuem métodos de negócio/comportamento e não só dados (como é o caso dos seus VOs). Dessa forma, a sua camada de serviço retorna objetos sem estes métodos que não deveriam ser utilizados em outras camadas. Outra utilidade de DTOs é quando se usa o Hibernate, para evitar que as camadas superiores utilizem os proxys retornados por ele.
rodrigo.uchoa
Eu só usaria DTO em casos onde há chamadas remotas. Não faz sentido trafegar pela rede uma entidade JPA, inclusive pq você não sabe se o cliente que está fazendo a chamada tem acesso as libs JPA. Em casos normais, de sistemas web comum, acho exagero (salvo raras exceções). Mas mesmo no caso das exceções seriam só exceções… Usar isso como design padrão acho exagero mesmo.
Mais ainda, não vejo sentido em ter os dois conceitos na forma como você está usando. Os dois, tanto VO e DTO no seu design, estão atuando como DTOs.
javaflex
Quando é para enviar objetos para outra camada remota com certeza DTO é muito importante, como falaram aqui sobre o caso do Hibernate x camada remota. Eu utilizava DTO quando trabalhava com Flex.
rodrigo.uchoa
Decisões de design como essa realmente são difíceis de fazer. Eu tento seguir sempre a maior simplicidade possível. Para usar DTO/VO como está falando, só se houvesse uma justificativa MUITO relevante. Na dúvida, eu nunca colocaria.
kcobainnn
Como já disseram, é questão de gosto, mas, falando a minha opinião:
Antigamente, isso era quase obrigatório, por exemplo, trafegar suas entidades em diferentes projetos, antes era algo impossível se você estivesse usando o EJB 2.1 por conta dos entity beans, o uso de DTOs era obrigatório porque senão… você não tinha escolha.
Hoje, a história é totalmente diferente, as entidades JPA são portáveis, você não tem mais essa necessidade de ter que recriá-las em DTOs.
No meu caso, dependendo, eu costumo trafegar as entidades até em diferentes projetos, costumo usar DTO quando eu quero esconder a lógica de negócio da minha entidade ou quando estou usando WebServices, aí sim, eu crio um DTO para trafegar os dados e disponibilizo para os clients da aplicação.
