Sobre o Pattern Repository
Em contra partida ficar usando diretamente o EntityManager ou o Session na camada de negócio não é legal, não tanto por "misturar" as coisas, mas quando criamos as consultas, muito provavelmente ela serão repetidas ao longo do sistema. O ideal é agruparmos estas consultas em algum lugar, e já que estamos agrupando as consultas, porque também não criarmos os métodos de CRUD? Puxa, mas os métods de CRUD nada mais faram que delegar ao EntityManager ou Session a tarefa, coisa chata de ficar repetindo código.
Bem, todo repositório tem que ter os CRUDs básicos, então porque não criar uma classe AbstractRepository com as tarefas de CRUD? A minha AbstractRepository segue mais baixo. Na verdade a que eu uso tem mais alguns métodos para pesquisas genéricas, mas a classe abaixo já da conta dos CRUDs da vida.
[code=java]
public abstract class AbstractRepository<T> {
public void save(T t) {
HibernateSessionFactory.getSession().save(t);
}
public void delete(T t) {
HibernateSessionFactory.getSession().delete(t);
}
//Esta seria possível implementar conforme este texto
//http://blog.caelum.com.br/2006/10/29/brincando-com-generics-o-bizarregenericdao/
public abstract T find(Serializable id);
public void merge(T t) {
HibernateSessionFactory.getSession().merge(t);
}
}
[/code]
Assim os Repository que extendem da AbstractRepository não precisam implementar os métodos básicos e repetitivos de CRUD.
Re: Sobre o Pattern Repository
Um Repositório muitaz vezes vai ter apenas um método de pesquisa e em boa parte das vezes este método vai ter um mapeamento de 1 para 1 com um método exposto num DataMapper (DAO). Neste caso creio que a solução mais simples seja criar uma interface de negócios e fazer o DAO implementá-la. É mais simples e eficiente.
[]s
Re: Sobre o Pattern Repository
Desculpe a demora, mas ainda não tinha visto o comentário pendente. Ainda estou aprendendo o Pebble e ele ainda esta configurado para que todos os comentários terem que ser aprovados.
O problema de herdar métodos que não são usados é uma coisa que esta acontecendo em um projeto particular (novidades por ai depois) no qual estou aplicando este esquema de Repositórios. É um problema na hierarquia do modelo mesmo, porém não é uma coisa que impacta, apenas são métodos herdados que não são usados, mas pelo menos não tenho o trabalho de (re)implementa-los.
A idéia da interface é legal. Vou tentar aplica-la e depois escrevo mais alguma coisa por aqui (bom que tenho mais assunto para este blog :-) )
Mas eu não quero cair numa DAO. Quero que minha DAO seja o Hibernate mesmo
Value pela visita.
[]´s
Alexandro
<span class="unauthenticated" id="comment1195432096395.author"></span>
Re: Sobre o Pattern Repository
Phillip,
No táxi agora, no meio do trânsito, estava pensado sobre o assunto.
Acho que o AbstractRepository proposto por mim neste texto na verdade é um DAO com outro nome. O que se pode fazer é trocar o sufxo Repository por DAO, criarmos as interfaces Repositotys e cada DAO especialista implementar a interface Repository especifica.
O factory de Reposiory iria instanciar o DAO mas retornar a Interface Repository. Pelo que eu entendi, foi mais ou menos isso a sua proposta.
Acho válida, e a interface do Repository não ficaria tão poluida.
Ok, a sujeira ainda esta lá. Métodos genéricos possivelmente não utilizados do DAO implementados no AbstractDAO. Mas pelo menos estão escondidaos (protegidos?) atrás da Interface Repositoty. Acho um preço justo a se pagar pelo ganho de não ficar implementando métodos genéricos em todas especializações de DAO.
Mas também não descarto o uso do AbstractRepository da maneira que esta no texto, pode não ser belo, mas também não é feio, e funciona legal.
[]'s
Alexandro