O Pojo a que se refere não seriam os ‘entity’ a que me refiro? Outra coisa, segundo andei lendo muito, não é legal deixar a resposabilidade de persistência por conta dos Pojos (ou entity) e sim, a criação de um repository para isso.
Se eu estiver errado me corrija.
Mas minha dúvida original continua. O que trafegar entre a camada de apresentação e o repository? Seria os entity mesmo ou seria VO ou DTO ?? Os entities não são classes grandes demais, por conter regras de negócio, pra ficarem trafegando via RMI na rede ?
não, o que to falando é criar um objeto específico pra ser trafegado e com base nele criar seu entity que será persistido em base de dados.
sei o que vc está pensando pois como são nomes diferentes usados pra um mesmo conceito (pojo), mas vc lembra do padrão prototype, que vc cria objetos com base em um objeto prototipo, então, o que to querendo dizer é que vc vai ter um pojo (entity) pra trafegar e outro (copia) pra persistir e na copia vc poderia colocar regras de negocio.
Eu tenho a mesma dúvida inicial.
Acredito que o repository deve receber somente as entity para serem persistidas;
Seria mais ou menos o seguinte passo a passo:
Recupera o Entity
Recupera o DTO
Transforma o DTO em VO
Altera o Entity informando o VO
Grava o Entity
Eu não sei se é possivel passar o DTO direto para a Entity, se for, por favor, perdoe minha ignorancia;
É importante não confundir DTO ou TO com VO. DTO ou TO (Transfer Object) é um pattern J2EE do blueprint da Sun (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html) que tem como principal objetivo reduzir o overhead de acesso à rede quando trabalhamos com objetos remotos (Entity Beans ou Session Beans). O pattern propõe que os Business Objects remotos criem os TOs apenas como um repositório de dados, POJOs anêmicos (sem muita inteligência) , e acreditem se quiser, com propriedades utilizando modificadores de acesso public! A proposta é fazer com que a camada client recupere todos os dados do objeto de uma vez só através do TO e trabalhe com ele localmente. Depois manda tudo de volta pro BO e ele tem um método de merge que consolida tudo no modelo.
VO é um conceito utilizado em DDD (principalmente) para especificar as classes de negócio que não possuem identidade (obviamente, que não são do tipo Entity). Veja a explicação do Martin Fowler: http://martinfowler.com/bliki/ValueObject.html
Esta confusão é comum porque antigamente o blueprint da Sun trazia TO com o nome de Value Object, mas isto já foi editado, no entanto as imagens dos diagramas utilizadas na explicação do pattern ainda trazem o nome antigo.
Mais um adendo à minha resposta, agora mais relacionada à dúvida postada. Acho que o conceito de Repository (do DDD) tem mais a ver com design da aplicação, relacionada ao domain model. TO é mais um conceito de arquitetura, uma forma resolver um requisito não funcional no código da aplicação. Na minha opinião eu acho que você tenha que modelar seu sistema baseando-se no DDD e depois (se sentir necessidade) pensar em alguma estratégia como TO.
[quote=amhfilho]É importante não confundir DTO ou TO com VO. DTO ou TO (Transfer Object) é um pattern J2EE do blueprint da Sun (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html) que tem como principal objetivo reduzir o overhead de acesso à rede quando trabalhamos com objetos remotos (Entity Beans ou Session Beans). O pattern propõe que os Business Objects remotos criem os TOs apenas como um repositório de dados, POJOs anêmicos (sem muita inteligência) , e acreditem se quiser, com propriedades utilizando modificadores de acesso public! A proposta é fazer com que a camada client recupere todos os dados do objeto de uma vez só através do TO e trabalhe com ele localmente. Depois manda tudo de volta pro BO e ele tem um método de merge que consolida tudo no modelo.
VO é um conceito utilizado em DDD (principalmente) para especificar as classes de negócio que não possuem identidade (obviamente, que não são do tipo Entity). Veja a explicação do Martin Fowler: http://martinfowler.com/bliki/ValueObject.html
Esta confusão é comum porque antigamente o blueprint da Sun trazia TO com o nome de Value Object, mas isto já foi editado, no entanto as imagens dos diagramas utilizadas na explicação do pattern ainda trazem o nome antigo.[/quote]
Deixa eu aproveitar seu parenteses e tirar outra duvida então:
Digamos que estou trabalhando com as duas abordagens… Eu posso receber um TO e passar diretamente para uma entity para altera-la?
Caso não seja possivel… o que eu devo fazer??
Não sei se entendi bem sua pergunta, mas se você for utilizar TO (o pattern), para fazer uma alteração de dados, você tem que passá-lo para um Business Object, que seria um Entity Bean ou Session Bean. De acordo com a documentação do pattern:
[quote]Updatable Transfer Objects Strategy
In this strategy, the Transfer Object not only carries the values from the BusinessObject to the client, but also can carry the changes required by the client back to the business object.[/quote]
Uma sugestão: avalie se realmente é necessário utilizar isso.
Cria uma factory que pega os dados do seu form e cria o objeto de domínio. No livro Effective Java do Joshua Bloch tem umas estratégias muito legais para criação de POJOs sem utilizar construtor, inclusive adotando uma abordagem de Builder. ( http://pt.wikipedia.org/wiki/Builder)
Aí você pode delegar para um Service ou utilizar uma abstração de Repository para gravar no banco. Esta última é mais elegante.
Se você não quiser que sua camada de View acesse o Domain diretamente, você vai ter que criar uma camada de Service ou Application e fazer esta ponte.