Melhor maneira evitar VO entre cliente e session-facade

Programação Java
#1

Ae pessoal!!

Estou com o seguinte problema… venho iniciando no EJB 3 esses dias, e me deparei com o dilema do VO.
Gostaria que algum expert me esclarecesse algumas duvidas. Por exemplo:

Não existem mais entitie-beans, portanto eles não possuem mais interface home / remota. Logo, como instanciarei eles no cliente dado que o cliente não conhece as API da JPA ?

Qual seria a melhor maneira para se evitar o uso de VO entre o cliente e o session-facade na especificação EJB 3.0 ?

Como que o struts vai fazer a injeção de dados do meu formulário web sem VO ?

“Copiar” os atributos da entity no próprio facade, e dentro do facade instanciar a entity replicando os atributos ?

Fazer o struts instanciar o session-facade ?

Sei lá, fikei meio perdido… se alguem puder esclarecer, eu agradeço! valew

#2

[quote=gibaholms]Ae pessoal!!

Estou com o seguinte problema… venho iniciando no EJB 3 esses dias, e me deparei com o dilema do VO.[/quote]

Dilema do VO? Acabe com o dilema acabando com o VO!

[quote=gibaholms]Gostaria que algum expert me esclarecesse algumas duvidas. Por exemplo:

Não existem mais entitie-beans, portanto eles não possuem mais interface home / remota. Logo, como instanciarei eles no cliente dado que o cliente não conhece as API da JPA ?[/quote]

O que? Você está misturando alhos com bugalhos. O que tem a ver entity beans com interface home? O que tem a ver instanciação no cliente com JPA?

Recapitulando EJB 3.0 e JPA:
Quando você quer se referir a um EJB, você declara a interface EJB como atributo de classe anotado com @EJB (essa classe precisa ser Servlet, ManagedBean ou um bean do Spring). Caso você não tenha uma classe gerenciada por container, vai ter que buscar o EJB via JNDI, a diferença é que lá não vai estar a home, onde você deve dar create pra te devolver um stub, o próprio stub vai estar lá.

Quando um objeto anotado com JPA estiver no cliente, a lib de JPA deve estar lá, não tem jeito infelizmente.

Simples, não pense em termos de VO, pense em quais métodos o objeto possui, quais os relacionamentos com outros objetos. Se for o caso, encapsule chamadas a métodos EJB dentro desses objetos.

[quote=gibaholms]Como que o struts vai fazer a injeção de dados do meu formulário web sem VO ?

“Copiar” os atributos da entity no próprio facade, e dentro do facade instanciar a entity replicando os atributos ?

Fazer o struts instanciar o session-facade ?[/quote]

Não conheço Struts, graças a Deus. Siga um conselho que me deram: livre-se do Struts.

Bom, vou responder a sua pergunta, supondo a existência de um façade similar ao Faces ou ao Struts 2: o objeto devolvido pelo EJB precisa de alguns getters e setters, não tem jeito. Então, passe eles pra view.

#3

Cara… antes de tudo, obrigado pela resposta, mas algumas coisas ainda não ficaram 100% claras na minha cabeça hehehe

Estou debugando sua resposta e pegando algumas coisas interessantes que me ajudem a esclarecer… vamos lá:

Ai vem uma coisa bem engraçada… concordo plenamente com você, é que comprei um livro chamado:
“Guia do Java Enterprise Edition 5 - Desenvolvendo Aplicações Corporativas”, Cleuton Sampaio de Melo Jr. - Ed. Brasport.

Estava eu procurando algum livro barato sobre EJB3 e encontrei esta pérola, onde o cara me fala que VO é um “Padrão de Projeto”… uhauhaahuhuauhahuauh… apesar de ir contra tudo que já havia lido por aí, a gnt sempre fica com uma pulguinha na cabeça neh… bom, mas esse cara tem uns 90 anos de idade, então vamos dar um desconto pra ele.

Até aí, tudo bem.

Quando o cliente precisar referenciar uma entity persistente (com as anotações de entity, campos etc… do JPA) do servidor (como retorno de uma listagem por exemplo), ele precisará ter a api do JPA mesmo nunca usando ela !!! Poxa, o cliente só precisa de um objeto pra popular os campos e mostrar pro cliente, não precisa persistir nada. Por isso pensei num VO aí no meio. Existe alguma maneira mais “correta” de se fazer isso !!!

Tipo, não estou conseguindo visualizar isso, me ajuda por favor!! Me descreve como seria um sistema bem simples, sem struts nem nada… apenas uma JSP com um formulário de dois campos text: nome e endereço. Uma entity persistente JPA com os campos String nome e endereço. Um bean stateless DAO com o método salvar(), que cria os entity-managers e persiste a entity.

Agora, como que eu passaria esses campos “nome” e “endereço” pro bean stateless sem que o cliente conheça a entity (que seria onde o livro fala pra usar VOs) ? Qual é a melhor forma de se fazer isso ?

obrigado!

#4

A forma mais simples é deixar o cliente conhecer a entidade. A entidade é omnipresente no sistema. Ela é cross-layer , cross-tier, cross-store. Ou seja, ela pode viajar porque ela é o sistema.
Mas se vc não quer isso, vc precisa de um UIEntity. Ou seja um objeto igual ao outro mas que fica na camada UI. Obviamente isso é um tiro no pé, mas pode ser interessante quando a sua UI é feita de muitas entidades ao mesmo tempo. Depois, vc precisa de uma classe de modelo que traduz o UIEntity para o serviço de fachada que por sua vez cria o entity normal e continua dai. Entre o model e o façade vc terá que usar objetos padrão para que não haja acoplamento, como Map ou assim… So que ai vc estará usando o padrão V{D(T)}O que é o que quer evitar. Além que esta opção tem imensa replicação e é muito complexa. Mas é pouco acoplada.

A minha dica é : use a própria entidade. Não a acople a nenhuma tecnologia. (não use JPA para começar e não terá problema).
Se não poder seguir isto use V{D(T)}O . Não ha vergonha em usar V{D(T)}O quando não ha outra solução.
Aliás, numa sistema distribuido tem que usar algum tipo de V{D(T)}O (mesmo que por baixo dos panos). Não existe outra forma.

#5