Pessoal to aprendendo ejb pois vou precisar usar num sistema.
Vi num local que me deixou confusa:
O ejb3 era declarado como Remote e Stateless, o que pegou foi que dentro dele declarava EntityManager, pra usar para persistir dados com JPA.
Mas isso não seria minha classe DAO onde tenho métodos de persistência? ou seja, meu EJB é apenas um DAO remoto neste caso???
teoricamente, no EJB eu teria minha regra e ele TERIA um objeto DAO, pra que o cliente acesse o remotamente o EJB e este acesse o DAO? ou estou errada?!
Pessoal to aprendendo ejb pois vou precisar usar num sistema.
Vi num local que me deixou confusa:
O ejb3 era declarado como Remote e Stateless, o que pegou foi que dentro dele declarava EntityManager, pra usar para persistir dados com JPA.
Mas isso não seria minha classe DAO onde tenho métodos de persistência? ou seja, meu EJB é apenas um DAO remoto neste caso???
teoricamente, no EJB eu teria minha regra e ele TERIA um objeto DAO, pra que o cliente acesse o remotamente o EJB e este acesse o DAO? ou estou errada?!
Carol, sim e não. Seu EJB poderia ser considerado um dao(eao - para entidades), se ele fosse uma classe especializada em tratar com um certo tipo de entidade. Não pois, dentro do seu EJB vc poderia ter métodos do negócio e eles podem utilizar o entityManager injetado pelo servidor de aplicações.
Mas para maior coesão vc poderia criar um EJB especializado para manipular um certo tipo de entidade e ele seria o seu DAO, vc poderia injetando-lo em um outro ejb que cuida somente da regra de negócio. Ou criar uma classe separada para ser seu DAO e instancia-la no seu EJB de negócio. Que foi o que você disse na sua última frase.
Com ejb3 vc pode injetar um entityManager com a anotação @PersistenceContext em qualquer ejb caso precise e isso não o tornará um DAO.
carol_programadora
entendi obrigada, mas então me diz o seguinte:
Se eu criar um ejb que vai ser remoto, nele colocar minha regras de negócio e acessar um outro ejb sendo um DAO… ou seja, criei meu componente de negócio…
vamos supor que eu queria chamar no ejb um método salvar().
e eu tendo uma aplicação web cliente, no meu controller eu chamo diretamente meu salvar() ejb remoto?
eu não deveria ter uma uma camada a mais no cliente, invés de chamar diretamente do controle, algo entre o controle e o ejb? ou não?
Rapapel
carol_programadora:
entendi obrigada, mas então me diz o seguinte:
Se eu criar um ejb que vai ser remoto, nele colocar minha regras de negócio e acessar um outro ejb sendo um DAO… ou seja, criei meu componente de negócio…
vamos supor que eu queria chamar no ejb um método salvar().
e eu tendo uma aplicação web cliente, no meu controller eu chamo diretamente meu salvar() ejb remoto?
eu não deveria ter uma uma camada a mais no cliente, invés de chamar diretamente do controle, algo entre o controle e o ejb? ou não?
Não necessariamente poderia ser desse jeito que vc falou, mas você pode criar uma camada SessionFacade(um ejb) para receber as requisições. Que será um EJB que agrupa e delega chamadas a métodos em determinado contexto do negocio, com isso vc diminui as chamadas remotas(muito custoso) chamando a facade que agrupa as funcionalidades locais(menos custoso).
Ai vc chama os métodos da facade do seu cliente web.
Com isso vc teria três camadas, facade(EBJ), uma camada de lógica de negocio(EJBs de negocio) e uma de persistencia(DAO).
allanmarques
Rapapel:
carol_programadora:
entendi obrigada, mas então me diz o seguinte:
Se eu criar um ejb que vai ser remoto, nele colocar minha regras de negócio e acessar um outro ejb sendo um DAO… ou seja, criei meu componente de negócio…
vamos supor que eu queria chamar no ejb um método salvar().
e eu tendo uma aplicação web cliente, no meu controller eu chamo diretamente meu salvar() ejb remoto?
eu não deveria ter uma uma camada a mais no cliente, invés de chamar diretamente do controle, algo entre o controle e o ejb? ou não?
Não necessariamente poderia ser desse jeito que vc falou, mas você pode criar uma camada SessionFacade(um ejb) para receber as requisições. Que será um EJB que agrupa e delega chamadas a métodos em determinado contexto do negocio, com isso vc diminui as chamadas remotas(muito custoso) chamando a facade que agrupa as funcionalidades locais(menos custoso).
Ai vc chama os métodos da facade do seu cliente web.
Com isso vc teria três camadas, facade(EBJ), uma camada de lógica de negocio(EJBs de negocio) e uma de persistencia(DAO).
Rapapel,
nesse caso os SessionFacade seriam Session Beans remotos?
Vê se eu entendi: Para salvar um objeto da sua camada de negócios a partir de uma servlet (um controller, por exemplo), você chamaria um método salvar que estaria no session bean. É isso?
Usar remote só faria sentido se a servlet estivesse rodando numa JVM e os session beans em outra, certo?
Rapapel
allanmarques:
Rapapel:
carol_programadora:
entendi obrigada, mas então me diz o seguinte:
Se eu criar um ejb que vai ser remoto, nele colocar minha regras de negócio e acessar um outro ejb sendo um DAO… ou seja, criei meu componente de negócio…
vamos supor que eu queria chamar no ejb um método salvar().
e eu tendo uma aplicação web cliente, no meu controller eu chamo diretamente meu salvar() ejb remoto?
eu não deveria ter uma uma camada a mais no cliente, invés de chamar diretamente do controle, algo entre o controle e o ejb? ou não?
Não necessariamente poderia ser desse jeito que vc falou, mas você pode criar uma camada SessionFacade(um ejb) para receber as requisições. Que será um EJB que agrupa e delega chamadas a métodos em determinado contexto do negocio, com isso vc diminui as chamadas remotas(muito custoso) chamando a facade que agrupa as funcionalidades locais(menos custoso).
Ai vc chama os métodos da facade do seu cliente web.
Com isso vc teria três camadas, facade(EBJ), uma camada de lógica de negocio(EJBs de negocio) e uma de persistencia(DAO).
Rapapel,
nesse caso os SessionFacade seriam Session Beans remotos?
Vê se eu entendi: Para salvar um objeto da sua camada de negócios a partir de uma servlet (um controller, por exemplo), você chamaria um método salvar que estaria no session bean. É isso?
Usar remote só faria sentido se a servlet estivesse rodando numa JVM e os session beans em outra, certo?
Opa blz?
Sim, seriam remotos.
Sim, o método estaria no session bean.
Remoto ou local depende da necessidade, no exemplo da carol seriam remotos.
Não questionei a necessidade de ser remoto, estou partindo do principio que seja em outra jvm pq ela citou remoto.
O verdadeiro intuito do SessionFacade é: imagine vc com um bean de negocio remoto, tendo que chamar 3 metodos do bean remoto um atras do outro, essas 3 chamadas poderiam ficar em uma granularidade alta dentro de um mesmo método da SessionFacade. 3 chamadas remotas x 1 chamada remota e 3 locais.
T+
allanmarques
Rapapel,
obrigado pelos esclarecimentos. Compreendi legal agora.
[]s
A
andre_salvati
carol_programadora:
eu não deveria ter uma uma camada a mais no cliente, invés de chamar diretamente do controle, algo entre o controle e o ejb? ou não?
Sim, vc está certa. O ideal é que não existam dependências EJB -> EJB, então vc acaba orquestrando chamadas a diversos componentes numa camada intermediária. Isso é o que chamam por aí de “orquestração de serviços” ou de “composição de serviços”. Geralmente, os ESBs que possibilitam a implementação de padrões de integração são boas soluções para resolver esses problemas, mas fatores como o escopo do seu projeto podem levar a abordagens melhores.
Não acredite em receitas de bolos que pregam a adoção de 200 camadas em sua arquitetura. Cada caso é um caso e deve ser analisado cuidadosamente.
