Bom dia,
eu tenho um EJB Generico responsável por persistências que é exposto para os clientes através de um Service. No entando estou tendo a necessidade criar alguns EQLs dinamicos (baseado em alguma entrada do usuário) em praticamente em todas as minhas classes. Estou na dúvida se eu crio um método no meu EJB Generico que recebera por parametro essa EQL personalizada ou abandono a idéia de EJB Generico e crio um pra cada classe mesmo.
Alguém tem alguma sugestão?
grato.
EJB “entity bean” genérico? Que monstro é esse?
Você precisa saber o que é “o monstro” para responder a dúvida?
Bem, de qualquer forma aí vai: é um serviço responsável por realizar as tarefas de persistência da minha aplicação. Porém ao invés de cada classe minha ter um desses eu criei um que executará a tarefa independente de quem será persistido.
Ah, entendi. Em vez de usar “EJB Entity Beans”, você está usando um Session Bean que faz a tarefa de persistência para você. Mas aí onde é que entra o EQL nessa história?
Não devo ter sido claro no primeiro post. Vou tentar reformular então.
Tenho um SessionBean(SB) que é responsável por realizar a persistência de EntityBeans(EB). Entenda por persistência todo e qualquer tipo de troca de infomações com o “repositório” (no caso um SGDB), ou seja, tanto gravação como recuperação. Para evitar de eu criar um SB para cada EB, ou criei um SB “genérico”, ou seja, ao invés dele receber um Usuario ele recebe um Object (no caso eu estou usando Generics, mas isso não importa). Porém, surgiu a necessidade agora, de mediante alguns parametros do sistema, eu ter que criar EQLs dinamicas, ou seja, eu leio os parametros de entrada e crio dinamicamente uma EQL baseada nesses parâmetros. Então surgiu uma dúvida em relação a “melhor arquitetura” para esse cenário:
Coloco isolo minhas EQLs em classes de “serviços” na própria app cliente e passo por parâmetro para o SB Generico que terá um método que executará essa EQL recebida, ou devo criar realmente um SB para cada classe e ele seria responsável por criar e executar essa EQL?
Hum… acho que a sua ideia original é melhor (passar o EQL como parâmetro). De fato, quanto menos classes (já que as SBs que você iria criar só são basicamente classes de acesso a dados, como você já percebeu) melhor.
Mas imagino que esse primeiro cenário fere a separação “conhecimento”, fere o conceito de camadas já que quem é responsável pela persistência de meus objetos é o SB e no cenário 1 será a app/classes/módulo client que terá o “conhecimento” de como montar uma consulta para a recuperação de objetos.
Talvez você me pergunte: “se já tem a resposta então porque perguntou”. Na verdade eu não sei a resposta, eu apenas acredito que pelos conceitos que estudei a primeira opção é conceitualmente errado, porém a segunda opção é muito mais trabalhosa e por isso postei a dúvida para ver se alguém já tenha passado por isso e poderia me dar uma luz.