Repository x Spring x Hibernate

Olá,

Tenho uma dúvida conceitual sobre Repository que seria o seguinte:

Imaginem que tenho uma entidade de negócio Conta, mapeada e persistida pelo hibernate. Essa entidade possui um método getSaldo() que me retorna o saldo atual.

A implementação de getSaldo() seria a seguinte:

O saldo será o resultado de todos os créditos menos os débitos. Isso poderá estar no banco ou não.

Considero que getSaldo() faça parte do negócio, portanto, faz sentido chamar um Repository dentro da entidade para retornar o saldo.

Agora a dúvida: sendo que eu utilizo Hibernate e Spring, qual seria a melhor forma de injetar o Repository na entidade?

Obrigado a todos.

1) Criá-la através de uma Factory
2) Fazê-la usar um Service, se fizer sentido no domínio

This message was edited 1 time. Last update was at 12/03/2008 08:15:13

E como implementar isso de forma menos "intrusiva"?

Seria interessante, por exemplo, fazer:

ou ainda

Já que estou usando spring, seria interessante injetar o Repository nesses caras, mas nesses casos não teria como fazer isso de forma totalmente transparente.

Sei algumas formas de resolver isso, mas nenhuma me cheira muito bem, não sei se é coisa da minha cabeça...

1) Voce ta falando de DAO ou Repoitorio?
2) Seu segundo exemplo nao faz muito sentido. Voce acabou de criar a conta, que saldo ela vai ter?

Da um caso de uso de exemlo.

pcalcado wrote:1) Voce ta falando de DAO ou Repoitorio?

Minha questão é relativa ao repository. Você deve estar fazendo essa pergunta pelo "daoCliente" do exemplo, né? Esse é um dao mesmo que tá me retornando um cliente que possui referência a uma conta - como eu disse, é meio tosco o exemplo, mas não me veio nada melhor na cabeça.

A questão é: em que momento o repository que é referenciado por conta vai ser injetado nele (Veja que eu consultei um cliente, não uma conta)? Qual a melhor forma de fazer isso?

pcalcado wrote:2) Seu segundo exemplo nao faz muito sentido. Voce acabou de criar a conta, que saldo ela vai ter?

Nesse caso não faz muito sentido mesmo. Mas ainda assim, poderia retornar 0. Podem haver casos que faça sentido, como falei estou sem exemplos melhores. Mesmo assim, se não fizer sentido, o método está lá... o que seria mais correto? Um IllegalStateException? Um valor default?

pcalcado wrote:Da um caso de uso de exemlo.

Não estou com um problema real, é mais uma dúvida arquitetural e conceitual mesmo... e nem é por falta do que fazer... rs.

Porque você não injeta ao recriar o objeto no DAO?

This message was edited 1 time. Last update was at 12/03/2008 10:24:06

Eu imaginei que você diria isso, por isso eu não fiz direto daoConta.get() e sim daoCliente.get().

Acho que fica complicado eu fazer isso no dao porque eu poderia ter cliente.getBanco().getConta().getSaldo(). Ou seja, quem vai criar todo esse grafo de objetos pra mim é o hibernate. Eu teria que sair varrendo eles pra injetar esse cara? E se eles estiverem vindo por lazy pra mim, vou forçar o seu carregamento? Ruim isso, né?

Uma idéia pra injetar o repository seria no interceptor. Funciona. Parece ser a solução menos intrusiva que eu encontrei até agora. Mas ainda assim não me agrada. O que acho ruim nesse caso é que saio um pouco do controle do spring (EU estou garantindo que ele será injetado) - e já que estou usando spring, ele deveria cuidar disso pra mim. Vou ter que criar uma fábrica pra isso, ou chamar um bean do spring diretamente... não gosto muito disso.

Ele também não funciona com um objeto em que EU dei new.

Mas aí entra outra questão: como este método deveria se comportar nesse caso? Talvez com uma das opções que eu disse no meu post anterior. Qual a sua opinião?

Quando sugeri DAO eu não pensei em Hibernate ou qualquer infra-strutura. Se você está usando Hibernate pode sim usar interceptors sem problemas.

Lembre-se que o Spring não faz que nada, e em especial ele não faz persistência (recriar e salvar). Na verdade o pring sequer trabalha com Entity, le trabalha com Services.

Para o que foge ao seu escopo o Spring trabalha em conjunto com outros frameworks e bibliotecas, então se a solução passa por Hibernate e eus interceptors isso não é problema.

Mas essa seria uma forma "usual" de se injetar reporitories em entidades de domínio?

Depende do que você chama de usual. Essa é uma forma de fazer, não é a mais indicada para todos os casos.

Na verdade não é muito comum -apesar de não haverproblema real- ter uma Entity que acessa Repository diretamente.

pcalcado wrote:Na verdade não é muito comum -apesar de não haverproblema real- ter uma Entity que acessa Repository diretamente.

Mas essa não é uma das idéias do Repository??? Se não, quem deveria retornar o saldo nesse caso? Cade os objetos "inteligentes"?

This message was edited 1 time. Last update was at 12/03/2008 21:29:21

No Conexão Java eu levei uma conversa com o Paulo Silveira sobre este assunto e um ponto importante foi levantado na utilização de interceptors do Hibernate neste caso, ele pode acarretar problemas caso em algum lugar do sistema você instancie diretamente a entidade (caso alguém esqueça de setar o Repository neste caso: NPE).

Eu optei por utilizar AOP, marcando um pointcut na instanciação do objeto, com isso tanto faz se quem cria o objeto é o JPA, o conteiner, o porteiro, a faxineira ou eu mesmo com um new. Na thread abaixo eu postei um modelo de aspecto com comentarios que talvez possa lhe ajudar. No código em questão eu utilizei o Jboss Seam, mas não muda muita coisa se você utiliza o Spring:

http://guj.com.br/posts/list/70275.java#369353

Uma dúvida quanto a sua modelagem:
Os dados necessários para a tomada de saldo no classe Conta, como créditos e débitos, não fazem parte natural da modelagem desta mesma classe? Não faz mais sentido você trabalhar com estes atributos (sendo classes compostas ou não)diretamente no modelo, fazendo de getSaldo um método que manipule estes dados?

@J2Alex
Não extamente. A idéia é que os objetos de negócio podem se comunicar e como falei no meu post não há problema em fazer isso, so Não é comum. Mas existem milhões de maneiras de implementar isso sem chamar o Repository diretamente, Lazy Loading é uma delas, ter o saldo como uma tributo é outra.

@Lezinho
Não ia ser mais fácil apenas criar uma Factory e não deixar o objeto ser instanciado sem ela?

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Hi Phillip ...
A equipe utilizando DIP por todo o lado nas outras classes, poder fazer um simples:

... em uma entidade dá um ar de naturalidade no código

.

Além de que com isso, não é apenas um repositório que você pode injetar, mas qualquer classe... como Gateways.

Acho que em vez de DIP (dependency Inversion Principle) você quis dizer DI (dependency injection), não?

De qualquer modo, pensei melhor e já que você já está usando Spring e ele tem um bom suporte à AOP não vejo porque não usar. Se tivesse que adicionar algo só ara isso, entretanto, usaria o mais simples, Factories e amigos.

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