DAO com IoC

Estou fazendo um DAO, e quero que ele não fique acoplado a nada além de uma Connection do banco de dados ou a uma Session do Hibernate.

Não quero que ele seja acoplado a um HibernateUtil por exemplo, que pega a session do ThreadLocal.

Quem injetaria a session no DAO ???

O container ???

Um filtro ???

A action ???

Se for o container, acho que dá para fazer a mesma coisa mais simplesmente com um filtro né ? Mas aí o filtro teria que acessar diretamente o DAO que está na action.

A última opção é o filtro passar para a action que vai passar para os seus DAOs. Mas não sei se isso é legal...

Com IoC a regra é: quem cria configura.

Salvo os casos onde vc faz attachments de objetos externos ao container.

Então pode ser as actions que estão criando os DAOs ???

Ou devo criar os DAOs em factories, e elas que se encarregarão de configurar isso ???

É boa prática passar a session para a action (via filtro) e essa por sua vez injeta no model ???

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

saoj wrote: Ou devo criar os DAOs em factories, e elas que se encarregarão de configurar isso ???

Se eu naum usar IoC eu acharia que usar factories seria a idéia mais atraente.

Opa Sérgio,

Ó, pressupondo que o DAO vai ser um Singleton (normalmente ele não tem estado), encontramos um problema, porque a sessão do Hibernate ou uma conexão JDBC não são singletons e eu preciso sempre pegar um "novo" objeto desses a cada chamada de método dentro do DAO (mesmo que não seja exatamente um novo).

No Spring, agente pode usar "injeção de método", onde sempre que eu chamar um "getConnection()" ele vai injetar a dependência Connection que esse método precisa, mas eu ainda tenho que chamar o "get", do mesmo jeito que eu faria com a HibernateUtil. Não ganhei nada fazendo isso.

Já se o DAO não for um singleton, ele pode ter a conexão ou a sessão dentro dele mesmo, mas quando iniciar ela? Quando terminar? Quem é que vai chamar os métodos de iniciar e terminar? O meu código? Ops, feio, imagina chamar um método "connect()" e depois "commit()" num DAO? Matou a abstração toda dele.

Porque você não quer que uma hipotética implementação do DAO usando Hibernate não use uma HibernateUtil da vida?

Não quero acoplar o DAO a nada... Nem ao HibernateUtil... Quero que ele seja totalmente independente...

O que eu gostaria de fazer, e nao sei se é boa prática é:

DAO tem setConnection ou setSession do Hibernate.

Filtro Abre uma session ou connection e passa para a action

Action injeta Connection ou session do Hibernate via os setters acima.

Daos são executados, assim como o MODEL

Action retorna

Filtros fecham sessão, retornam connection, etc e tal.

Isso na prática me parece perfeito !!! E na teoria, faz sentido?

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

humm.. o que acham??

saoj wrote: Isso na prática me parece perfeito !!! E na teoria, faz sentido?

Eu já diria o contrário, na teoria parece perfeito, na prática é que a coisa vai ser complicada. Onde vai ficar as ThreadLocal que vão guadar a sessão e a transação do Hibenate? No DAO? Não dá, pode haver mais do que um DAO trabalhando dentro de uma mesma requisição.

Se a ThreadLocal ficar dentro do filtro, ainda pode ser que funcione, mas os DAOs obrigatoriamente deixam de ser singletons e vão ter que guardar a sessão e a transação em algum lugar, e se houverem vários DAOs na mesma requisição, todos vão ter que ser injetados.

Na boa, use Spring, isso já tá pronto

Thiago Senna wrote:humm.. o que acham??

public ClienteDAO { private PersistenceManager pm; public void setPersistenceManager(PersistenceManager pm) { this.pm = pm; } public void save(Cliente cliente) { pm.save(cliente); } }

Quem vai "settar" o PersistenceManager?

Como é que ele recebe as conexões?

O DAO é Singleton?

Onde tudo se "fecha"?

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

Maurício Linhares wrote: Quem vai "settar" o PersistenceManager?

Poderia ser via IoC! Eu prefiro esta abordagem.

Maurício Linhares wrote: Como é que ele recebe as conexões?

Particularmente gosto muito da idéia que você tem defendido e n posts e tópicos até aqui. Adoro o ThreadLocal.

Ou seja, a classe que implementa o PersistenceManager irá buscar a session ou a conexão em um HibernateUtil, ou ConexãoUtil que me traz a session ou connection da thread corrente!

Maurício Linhares wrote: O DAO é Singleton?

Não!

Maurício Linhares wrote: Onde tudo se "fecha"?

por exemplo...

Eu colocaria o comando pm.dispose() no filtro, da mesma que forma que vc sugeriu em n tópicos esta semana

Está legal fazer assim o gerenciamento da persistência? Tem alguma crítica ou possível melhoria?

Abraços!
Thiago Senna

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

nada melhor do que um exemplo concreto, naum é?

Um exemplo de caso de teste usando o HibernatePersistenceManager

Como é apenas o teste, eu inseria as dependências no próprio teste mesmo...

Mas no código de produção seria IoC..

Abraços!
Thiago

Mauricio, um DAO não precisa ser um singleton, de fato, não existe motivo para ele ser.

Me responde uma pergunta, se existirem mais de uma instância da mesma classe de DAO, podemos ter problemas? Se a resposta for diferente de um categórico SIM, já tá decidido que não deve ser um Singleton.

DAOs simples costumam não ter estado, mas não é incomum usar eles para abstrair esquemas toscos e legados.

Tive um caso que dependendo de algumas variaveis de ambiente, o usuário logado as tabelas e o mecanismo de busca mudavam. Ou seja, o DAO não era 100% stateless por que essas informações vinham no construtor dele.

Thread.start() Membro desde: 12/07/2005 12:46:51 Mensagens: 32 Offline

Maurício Linhares wrote:Opa Sérgio,
Quem é que vai chamar os métodos de iniciar e terminar? O meu código? Ops, feio, imagina chamar um método "connect()" e depois "commit()" num DAO? Matou a abstração toda dele.

E quem é que vai abir a transação e dar um commit ou rollback e fechar a sessão?

Começo a ver que foi criado uma tempestade num copo d'água devido ao código abaixo:

Nele eu estou passando uma session do hibernate para dentro de uma action, e isso foi motivo de muita discussão.

Estou pensando no seguinte cenário:

Sistema em produção:

- Filtro pega uma sessão da maneira que for (HibernateUtil, ThreadLocal, etc.) e colocar no INPUT da action ou injeta num setter da action. Se fosse Model-Driven injetaria diretamente no model (via getModel() da action)

- Action de posso da sessão, injeta no model ou DAO. A action não faz uso da session, apenas a repassa (injeta) para o model ou DAO.

- Action executa.

- Filtro fecha a sessão.

OBS: Quem cuida da transação é o MODEL ou DAO. Isso está fora da discussão aqui.

Ambiente de Testes

- Não há filtros.

- Não precisa injetar a session, pois o DAO ou o MODEL vão estar MOCKEADOS e não vão acessar o banco e dados. Pode meter um null na session e passar para a action.

- Executa-se a action

- Testa-se o resultado da action.

Ficou um pouco esquisito o item em vermelho, mas como o objeto vai estar mockeado pode até fazer sentido.

A pergunta meio que persiste. Se não for a action que vai injetar as coisas no MODEL / DAO que ela contem, quem fará isso.

Ao vamos acoplar o HibernateUtil dentro do DAO e dane-se... (naoooooo... agora o chato sou eu!

)

Thiago, a sua solução é bem legal. Só que acho que vc está acoplando o PersistenceManager a sua action. Vai ter que levar ele com vc para onde vc for.

A minha situação seria melhor descrita assim:

Tenho um model que precisa de uma session para fazer consultas loucas no banco-de-dados. Não tem DAO aqui. O meu model pode usar o HibernateUtil e ficar pra sempre dependente dele, ou pode receber via injection a session e ficar totalmente desacoplado. Se fosse a segunda opção, quem passaria a session pra ele? Pode ser o filtro ?

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

saoj wrote: Thiago, a sua solução é bem legal. Só que acho que vc está acoplando o PersistenceManager a sua action. Vai ter que levar ele com vc para onde vc for.

Depende de como vou usar o PersistenceManager.

Meu action só conhecerá o PersistenceManager se eu usá-lo na minha action, mas naum é isso que eu pretendo fazer. Quem conhece meu persistence manager são meus daos, ou melhor ainda, meu modelo... já que o PersistenceManager é uma interface.

Assim, independe se o meu modelo teráum método save ou o dao!

Na prática, eu iria utilizar chamadas ao persistence manager apenas para inciar transação e finalizar tranzações nos filtros! Portanto, minha action nem iria saber que o PM existe.. na verdade, não deve!

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