Fala galera,
Gostaria da opinião dos mais entendidos e experientes com Entity Beans em relação a melhor forma de se fazer relações entre eles, tipo as mais simples como one to one e one to many.
Pegando um exemplo tipico de Pedido e Itens de Pedido ( one to many ) seria correto manter uma Collection de interfaces remotas de Itens de Pedido no bean Pedido ou o melhor seria manter uma Collection de objetos PK de Itens de Pedido ?
No primeiro caso eu teria um metodo na interface remota de Pedido
public Collection getItensPedido() o qual retornaria as pks, dai eu teria que iterar essa Collection e chamar itensHome.findByPrimaryKey() para cada elemento, já na segunda abordagem essa chamada de finder nào seria necessário, pois cada elemento já é um ItensPedido…
Existe uma abordagem melhor ?
Qual a opinião de vcs ?
A partir da especificação EJB 2.0, foram criadas as interfaces locais, que diminuem bastante a sobrecarga de envio de mensagens remotas entre entidades. Para criar relacionamentos, utilize uma coleção destas interfaces remotas. Além de mais leves, seu acesso será transparente, não necessitando fazer buscas pela PK, no caso de se guardar uma coleção delas. Acho que qualquer livro razoável atual sobre EJB 2.0 deve mencionar este assunto.
Por exemplo, caso vc esteja utilizando JBoss e XDoclet, um relacionamento 1:n entre cliente e endereços ficaria assim:
O que eu coloquei aqui como exemplo era p/ CMP… Foi mal, acabei respondendo seu olhar direito o título do seu post.
Eu tenho mais experiência com CMP, mas meu palpite continua o mesmo: mantenha coleções de interfaces locais. Na hora de fazer o load, ou o store, etc… vc vai ter que manipular a chave primária…
Olá Cláudio, não sei qual é o seu nível de conhecimentos em ejb, o meu eu sei que é fraco, mas vou te indicar esse link: http://www.ejb-ql.com/part2.html
fala um pouco de relacionamentos.
A principal dúvida que tenho em relação a manter uma Collection de interfaces locais é em relação ao ciclo de vida dos EJBs, pois como se sabe a interface local ou remota aponta para um EJB Object e naum para a instancia do bean propriamente dita, e ( creio eu ) se o servidor fazer uma passivação dessa instancia de bean, o objeto que está na Collection pode não ser mais válido ( pode estar apontando para outra instancia ).
Não sei o quanto isso pode ser problema, pois as tabelas ditas como filhas também serão Entity Beans separados e de vida propria.
Em relação ao XDoclet, eu já o uso em conjunto com o plug-in Lomboz, e gostaria de saber onde consigo documentação sobre a nova versão ( acho que 1.2b ).
Quanto ao problema de passivacao, voce nao precisa se preocupar. Primeiro, a passivacao dificilmente ocorre, mas caso ela ocorra voce nao perde o objeto. Quando voce acessar o objeto ele vai voltar para a memoria. Assim, poderiamos pensar na passivacao como um mecanismo de swap de disco. Quando falta memoria, ele pega o objeto menos utilizado, passiva ele (joga para o disco) e puxa outro. Essa lorota de pool, reutilizacao, eh problema do container, nao seu. Por exemplo, o jboss trabalha com dynamic proxy. Entao possivelmente, quando for passivado, esse dynamic proxy “perde” o Bean em si. Quando voce for reutilizar, o proxy ve que esta passivado e faz o container puxar de novo o Bean agregado.
Agora quanto armazenar somente os pk numa colection ou as interfaces da relacao, sugiro que voce faca a analise levando em conta a seguinte coisa: a quantidade de acesso ao banco de dados para gerar as interfaces para a sua entidades. Vai que o container, para gerar essas interfaces para tu armazenar na colection puxe todos os registros do banco de dados, vai que se voce for botar 100 registros na colecao, ele faca 100 consultas no bd.
Sugiro que voce bote um logger de sql, faca um prototipo e analise a quantidade de SQL gerado para as duas situacoes e escolha a que seja de melhor performance, mesmo que isso implique em fazer varios findByPrimaryKey na mao grande, ja que queres usar o EJB 1.x (BMP)