Injetando no Entity

Prezados(as),

Tem como injetar as coisas num entity no EJB 3.0? Testei aqui e não funciona (pelo menos não no JBOSS). O código é mais ou menos esse:

Por um acaso o Spring faz isso?

Aguardo!

Rodrigo Yoshima

JavaTeenager Membro desde: 16/05/2005 08:47:08 Mensagens: 152 Offline

Boa pergunta.
Tentei implemtar o conceito de domain model (classe com comportamento) no EJB3 e senti que a plataforma não foi feita para isso, forçando a você fazer classes "burras" e jogando toda a lógica apenas nas sessions.
Tentei fazer injeção e não consegui não.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 521 Offline

Hummm... Pelo que estou estudando na especificação, me parece que esta injeção de dependência serve apenas para session beans, interceptors e message driven beans.

A propósito, para que você deseja ter a referencia de um EJB dentro de um entity?

JavaTeenager Membro desde: 16/05/2005 08:47:08 Mensagens: 152 Offline

Para criar classes "inteligentes" com comportamento seria interessante delegar os métodos do entity para um EJB.
Neste caso eu poderia criar um Especification ou Strategy (patterns) usando um session bean.
No exemplo dele, acho que seria assim:

Tentei fazer isso também e não consegui.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 521 Offline

Bom, pessoalmente acredito que esta não seja uma boa estratégia, pois o entity, principalmente se você está utilizando EJB, é um objeto que vai trafegar pela rede e não seria muito bom que ele carregasse uma instância de um stub de EJB dentro dele...

Sugiro criar um session bean com estas operações e passar o entity como parâmetro. Caso insista nesta estratégia eu sugiro que você considere a possibilidade de utilizar uma classe java normal (mesmo que esta seja um delegate para acessar um session).

JavaChild Membro desde: 31/03/2005 07:43:23 Mensagens: 144 Offline

rodrigoy wrote:

Por um acaso o Spring faz isso?

Não, os Entity não fazem parte do Contexto do Spring.

JavaTeenager Membro desde: 16/05/2005 08:47:08 Mensagens: 152 Offline

É Guerra, no meu caso foi a melhor alternativa que eu tinha pensado na época.
Delegar para uma classe que
chamava o session via JNDI.

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

Eu não acho que é uma alternativa legal chamar serviços de dentro do Entity. Na minha opinião, o entity deve ter inteligência, mas não a ponto de acessar outros serviços. Devem ter inteligências mais simples.

Afinal, na prática, inteligências pesadas envolvem várias entidades do banco, vários processamentos etc. Isso acho legal ficar em uma interface de serviço mesmo.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Será que não está faltando ai uma entidade chamada Duplicata? E esse objeto por sua vez tivesse o método cancelar()?

IMHO, é muito esquisito colocar um serviço dentro de uma entidade.

ALTERADO: aff, viajei. O objeto Duplicata já existe. Bem, acho que o próprio objeto deveria conter a lógica para cancelar a duplicata.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 521 Offline

Na minha opinião, colocar um método cancelar na clase Duplicata, sendo que este deve acessar um serviço remoto e atualizar o banco de dados, acho a mesma coisa que criar o método "inserir" dentro da própria classe Duplicata.

Acho que o correto seria criar um método cancelar() dentro da classe Duplicada para que ele gerenciasse o estado interno de uma instância quando a duplicada fosse cancelada. Desta forma existiria um serviço que pegaria uma instância de Duplicata detached, chamaria o método cancelar() e sincronizaria seu estado com o banco a partir de um EntityManger. Desta forma separaríamos a lógica de negócios do método cancelar() com a execução de um serviço que sincroniza isto com o banco de dados e possivelmente pode ser executado remotamente.

Esta é minha visão arquitetural de como resolver este problema. Aguardo a opinião do pessoal a respeito.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Guerr@ wrote:Na minha opinião, colocar um método cancelar na clase Duplicata, sendo que este deve acessar um serviço remoto e atualizar o banco de dados, acho a mesma coisa que criar o método "inserir" dentro da própria classe Duplicata.

Acho que o correto seria criar um método cancelar() dentro da classe Duplicada para que ele gerenciasse o estado interno de uma instância quando a duplicada fosse cancelada. Desta forma existiria um serviço que pegaria uma instância de Duplicata detached, chamaria o método cancelar() e sincronizaria seu estado com o banco a partir de um EntityManger. Desta forma separaríamos a lógica de negócios do método cancelar() com a execução de um serviço que sincroniza isto com o banco de dados e possivelmente pode ser executado remotamente.

Esta é minha visão arquitetural de como resolver este problema. Aguardo a opinião do pessoal a respeito.

Em minha opinião, é isso que você citou que deveria ser feito.

JavaTeenager Membro desde: 16/05/2005 08:47:08 Mensagens: 152 Offline

Guerra é bem interessante essa sua visão.
Vc poderia dar um exemplo.

O Okara complementou a minha visão:

A idéia é ter o serviço para utilizar um strategy.... Logicamente esse serviço não seria chamado remotamente...

Pelo que me lembro, a definição do Fowler ou do Evans é que um service seria uma tarefa que não é alocada "naturalmente" a um entity.

O problema é que se a arquitetura nos força a alocar tarefas a services por conta de dificuldades técnicas, acho que temos um problema.

Na minha idéia, quanto mais responsabilidades alocadas a entities melhor...

Rodrigo Y.

JavaTeenager Membro desde: 16/05/2005 08:47:08 Mensagens: 152 Offline

Vc tem como me explicar melhor isso ?

Notícias, artigos e o maior fórum brasileiro sobre Java