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.
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.
[quote=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.[/quote]
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).
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.
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.
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.
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.
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.