Pessoal , estou com duvida em relação aos DAO’s em um projeto EJB .
Devo eu fazer a camada DAO dentro de um projeto EJB ?
Se eu fazer o DAO como ela não é bean eu perderia o controle do container ( Perdendo IOC , CMT , Injenção de depedencia , etc … ) . Por outro lado ganharia separando a regra de negócio com DAO .
Uma solução que eu pensei e gostaria de saber se está certo é denotar todos os DAO’s como @Stateless e @Local e injetar eles como @EJB dentro do meus beans verdadeiros .
Isso está certo ?
[quote=Zaperjava]Pessoal , estou com duvida em relação aos DAO’s em um projeto EJB .
Devo eu fazer a camada DAO dentro de um projeto EJB ?
Se eu fazer o DAO como ela não é bean eu perderia o controle do container ( Perdendo IOC , CMT , Injenção de depedencia , etc … ) . Por outro lado ganharia separando a regra de negócio com DAO .
Uma solução que eu pensei e gostaria de saber se está certo é denotar todos os DAO’s como @Stateless e @Local e injetar eles como @EJB dentro do meus beans verdadeiros .
Isso está certo ?[/quote]
Bom, existem várias formas. Depende de cada caso. As principais são:
Injetar o Entity Manager no EJB e usar diretamente, sem fazer a DAO;
Fazer a DAO como se fosse um EJB (que é sua dúvida se está certo fazer isso. Na minha opinião, está sim)
Pode injetar o Entity Manager no EJB e passar ele no construtor de uma DAO;
Mas qual é o propósito do sistema, os requisitos? Realmente é necessário fazer DAO? Usar o EM diretamente não satisfaz o teu caso?
[quote=Maracuja][quote=Zaperjava]Pessoal , estou com duvida em relação aos DAO’s em um projeto EJB .
Devo eu fazer a camada DAO dentro de um projeto EJB ?
Se eu fazer o DAO como ela não é bean eu perderia o controle do container ( Perdendo IOC , CMT , Injenção de depedencia , etc … ) . Por outro lado ganharia separando a regra de negócio com DAO .
Uma solução que eu pensei e gostaria de saber se está certo é denotar todos os DAO’s como @Stateless e @Local e injetar eles como @EJB dentro do meus beans verdadeiros .
Isso está certo ?[/quote]
Olá, como vc diz que tem um projeto EJB mesmo, a sua solução esta correta.
Existe este artigo mto bom também se vc tiver tempo.
Generic Data Access Objects especialmente no seu caso “Writing DAOs as managed EJB 3.0 components”. Como ele cita neste artigo, tinha um outro artigo do Bill Burke que era a referencia que eu tinha, tive uma duvida parecida a 3 anos atrás… hehehe…
Muito oportuna a questão. É uma dúvida que muitos têm de usar DAO como EJB ou como classes normais. Eu particularmente uso as DAOs como Session Beans normais, já que assim eu ganho injeção de dependências (do Entity Manager, datasource e até resources), além disso o próprio container é bem inteligente em controlar o ciclo de vida. Além disso você pode injetar aos DAOs nos EJBs da camada de negócio, aproveitando o ciclo de vida controlado do container. Caso contrário você precisará fazer o new manualmente ou usar uma Factory.
Stateless é uma classe com instância que fica “guardada” no container, e cabe a ele decidir se deve fazer cache, destruir ou criar. A idéia por trás do EJB é abstrair o controle do ciclo de vida do programador. Enfim, a resposta é depende… isso o container vai decidir.
Eu prefiro sempre usar @EJB, ao invés de fazer lookup. Faço lookup apenas em EJBs remotos ou quando estou fora do ambiente gerenciado.
Obrigação de fazer isso você não tem não. Eu já ví projetos assim, mas eu não vejo muito ganho nisso. Eu uso normalmente em um projeto Enterprise um módulo web, um módulo EJB e um módulo client que contém as interfaces remotas e DTOs. Em uma outra empresa que trabalhei haviam muitos projetos, então tinha ainda um módulo commons com classes comuns a todos os projetos como classes uteis, etc.
Não, não vai perder. Sempre que você possui um módulo EJB irá funcionar todo o controle de injeções. Porém a injeção só funciona entre ambientes locais em uma mesma VM.
Oi. Me desculpe engatar a sua dúvida. Se quiser que eu edite e apague o que escrevi, é só falar. Mas me veio uma dúvida.
Se eu tiver uma interface (bea, remote) com os métodos crud, e fazer meus sessions (todos stateless) implementarem essa interface, pode ser considerado um DAO?
Perco alguma coisa? Performance, robustez, flexibilidade?
Outra. Fazer lookup (mesmo dentro do servidor, fazendo um lookup pra ele mesmo) é custoso? Em um sistema em que a classe A deve ser validada para ser inserida e, com isso, um log tenha que ser inserido (mas esse log tenha algumas particularidades, tipo regras de negócio que só fiquem no Session dele), eu teria que fazer lookup no session e mandar inserir, certo? Existe outra maneira de fazer isso?
Me desculpem se as dúvidas não ficaram coerentes. Estou muito cansado, mas não pude deixar de perguntar isso.
O que faz sua classe ser alguma coisa é “para que ela serve”, e não se você implementa ou estende algo. Se entendi bem isso que você tem é um session bean normal atuando como camada de serviço.
Não, o fato de você implementar ou estender alguém não significa que você perca performance.
Tudo tem um custo, até mesmo int i = 1 + 1. Mas o custom de fazer um lookup local é muito pequeno.
Garcia, muito obrigado.
Essa de fazer o lookup, eu estava dando uma olhada no nosso código. É, na verdade, o custo de um if e de um return (porque o contexto já vai estar criado - criamos ele no começo da aplicação, então só é feita a verificação de nulo e o retorno).
Sobre a primeira resposta, tem razão. É uma camada bem fina mesmo, mas com com muita funcionalidade (algumas regras de negócio ficam dentro dele, junto com as operações de banco). Não é estritamente um DAO, mas um serviço.
[quote=Zaperjava]Pessoal , estou com duvida em relação aos DAO’s em um projeto EJB .
Devo eu fazer a camada DAO dentro de um projeto EJB ?
Se eu fazer o DAO como ela não é bean eu perderia o controle do container ( Perdendo IOC , CMT , Injenção de depedencia , etc … ) . Por outro lado ganharia separando a regra de negócio com DAO .
Uma solução que eu pensei e gostaria de saber se está certo é denotar todos os DAO’s como @Stateless e @Local e injetar eles como @EJB dentro do meus beans verdadeiros .
Isso está certo ?[/quote]
Olá, como vc diz que tem um projeto EJB mesmo, a sua solução esta correta.
Existe este artigo mto bom também se vc tiver tempo.
Generic Data Access Objects especialmente no seu caso “Writing DAOs as managed EJB 3.0 components”. Como ele cita neste artigo, tinha um outro artigo do Bill Burke que era a referencia que eu tinha, tive uma duvida parecida a 3 anos atrás… hehehe…
