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:
public BigDecimal getSaldo() {
return this.repository.getSaldo(this);
}
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?
E como implementar isso de forma menos “intrusiva”?
Seria interessante, por exemplo, fazer:
Cliente cliente = daoCliente.get(1);
cliente.getConta().getSaldo(); // tosco, mas imagine que cliente tivesse apenas uma conta, pra simplificar...
ou ainda
Conta conta = new Conta();
conta.getSaldo();
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… :roll:
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?
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?
Não estou com um problema real, é mais uma dúvida arquitetural e conceitual mesmo… e nem é por falta do que fazer… rs.
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.
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:
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?
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.
Aspectos era justamente uma das outras alternativas que eu tinha pensado além dos interceptors… vou dar uma olhada no seu post.
E calcado, eu continuo não entendendo o que você diz em “não ser comum”. O próprio exemplo de Fowler sobre Repository mostra algo semelhante a isso e isso me parece bem lógico.
.