Duvidas sobre Dao + Hibernate + Repository

Entusiasta Java Membro desde: 01/06/2009 17:56:34 Mensagens: 18 Offline

Olá, pessoal já li várias discussões sobre Repository X Dao aqui no GUJ, mas ainda assim algumas dúvidas persistem. Atualmente
trabalho com uma arquitetura definida assim:

Uma interface Dao

A implementação com Hibernate

class HibernateDao<T> implements Dao<T> {
	protected Session session;
	protected Class<T> persistenceClass;

public HibernateDao(Session session, Class<T> persistenceClass) {
		super();
		this.session = session;
		this.persistenceClass = persistenceClass;
	}

public void save(T t) {
		session.save(t);
	}

public void save_or_update(T t) {
		session.saveOrUpdate(t);

}

public void delete(T t) {
		session.delete(t);
	}

public void update(T t) {
		session.update(t);
	}

@SuppressWarnings("unchecked")
	public T get(Serializable id) {
		return (T) session.get(persistenceClass, id);
	}

@SuppressWarnings("unchecked")
	public T load(Serializable id) {
		return (T) session.load(persistenceClass, id);
	}
	
	
	@SuppressWarnings("unchecked")
	public List<T> findAll() {
		Criteria c = session.createCriteria(persistenceClass);
		return c.list();
	}

protected Integer countByCriterion(Criterion criterion) {
		Criteria c = session.createCriteria(persistenceClass);
		c.add(criterion);
		c.setProjection(Projections.rowCount());
		return (Integer) c.uniqueResult();
	}

@SuppressWarnings("unchecked")
	public List<T> findAllByExample(T object) {
		Example example = Example.create(object).ignoreCase().enableLike(
				MatchMode.ANYWHERE);
		Criteria c = session.createCriteria(persistenceClass);
		c.add(example);
		return c.list();
	}

@SuppressWarnings("unchecked")
	public List<T> findAllByExample(T object, String orderBy) {
		Example example = Example.create(object)
					.ignoreCase()
					.enableLike(MatchMode.ANYWHERE);
		Criteria c = session.createCriteria(persistenceClass);
		c.add(example);
		c.addOrder(Order.asc(orderBy));
		return c.list();
	}

@SuppressWarnings("unchecked")
	public List<T> findAllByExampleWithPagination(T object, int min, int max) {
		Integer count = 0;
	
		Example example = Example.create(object)
		.ignoreCase()
		.enableLike(MatchMode.ANYWHERE);
		Criteria c = session.createCriteria(persistenceClass);
		c.add(example);
		
		count = countByCriterion(example);

if (count < max)
			max = count;

if (min >= 0)
			c.setFirstResult(min);
		if (max >= 0)
			c.setMaxResults(max);

return c.list();
		
	}

@SuppressWarnings("unchecked")
	public T findByExample(T object) {
		Example example = Example.create(object)
		.ignoreCase();
		Criteria c = session.createCriteria(persistenceClass);
		c.add(example);
		return (T) c.uniqueResult();
	}

}

Ai quando quero algum metodo novo crio uma interface tipo:

E implemento com um FuncionarioDaoImpl assim:

Ai disponibilizo uma Factory para criação dos Daos onde injeto a Session assim:

Agora minhas dúvidas :

Acabando achando desnecessário interface Dao, pois se por exemplo se amanha quiser mudar a camada de Persistencia para JPa por exemplo, ficaria dificl implentar metodos como findByExample,por isso acho minha interface acoplada demais ao Hibernate.

Então qual seria a desvantagem de não ter interfaces trabalhando direto com a implementação?

Outra dúvida, esse modelo acima, está mais para um Repository ou Dao, muito genta fala que o Repository e uma interface com Semântica melhor do que o Dao então neste caso poderia ter uma interface assim:

O problema aqui é, onde entraria os metodos findAllByExample, no Repository ou nos Dao's?

Como podem ver estou um pouco confuso com estes dos Patterns.

Se alguem puder esclarecer agradeço.

Rapaz, eu uso generic dao e não preciso estar colocando uma interface para cada dão não!

Uso só o daoFactory, o Dao e uma classe específica.. Exemplo UsuarioDao

Entusiasta Java Membro desde: 01/06/2009 17:56:34 Mensagens: 18 Offline

Olá moska obrigado pela resposta.

Entao você tem

Interface Dao
HibernateDao implments Dao

e tipo

UsuarioDao extends HibernateDao{

//metodo diferentes
}

Isso?

Vou exemplificar aqui com uma classe simples.

Classe de negócio

Agora meu daofactory que chama os respectivos daos e implementa métodos de conexão.

Agora o dao, que implementa a maioria das tarefas comuns de bancos de dados.

public class Dao<T> {

protected final Session session;
    @SuppressWarnings("unchecked")
    private final Class classe;

@SuppressWarnings("unchecked")
    public Dao(Session session, Class classe) {
        this.session = session;
        this.classe = classe;
    }

public void add(T obj) {
        this.session.save(obj);
        this.session.flush();
    }

public Serializable save(T obj) {
        Serializable r = this.session.save(obj);
        this.session.flush();
        return r;
    }

public void remove(T obj) {
        this.session.delete(obj);
    }

public void update(T obj) {
        this.session.merge(obj);
        this.session.flush();
    }

@SuppressWarnings("unchecked")
    public List<T> listAll() {
        return this.session.createCriteria(classe).list();
    }

@SuppressWarnings("unchecked")
    public T getById(Long id) {
        return (T) session.get(classe, id);
    }

@SuppressWarnings("unchecked")
    public List<T> findByExample(T obj) {
        Criteria c = this.session.createCriteria(classe);
        c.add(Example.create(obj).enableLike());
        return c.list();
    }

@SuppressWarnings("unchecked")
    public T getByExample(T obj) {
        Criteria c = this.session.createCriteria(classe);
        c.add(Example.create(obj).enableLike());
        return (c.list().size() > 0 ? (T) c.list().toArray()[0] : null);
    }
}

Agora um dao específico de uma classe. Que extende Dao e eu só preciso colocar os métodos que não foram implementados na classe Dao.
Mesmo que não haja nenhum método para ser implementado, eu vou precisar desta classe, para o sistema saber qual a entidade que eu estou usando através de generics.

Qualquer coisa, tamo por aí.

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Não faz muito sentido para a maioria dos casos se ter um DAO quando se está trabalhando com um framework ORM como JPA/Hibernate.

Isso acaba tornando-se um anti-pattern,
http://www.rponte.com.br/2009/06/08/no-more-daos/

Isso é questionável...

DAO, Repository, whatever... você precisa de alguma coisa para não expôr o mecanismo de persistência para o resto da sua aplicação.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

Outra coisa questionavel é o findByIsso findByAquilo. Existem algumas formas de se evitar isso, a mais simples com um map propriedade, valor de busca, que torna a interface do dao bem mais simples.

Interfaces normalmente parecem desnecessarias, mas normalmente somos nos que estamos pensando errado. Elas desacoplam completamente as classes clientes das implementacoes, se mesmo com o uso de interfaces elas continuam acopladas é porque estao sendo mal usadas.

Na verdade o que esta sobrando ai na sua aplicacao nao sao as interfaces, mas a factory dos daos. Use Spring e chute essa factory pra longe.

ravisantos wrote:Como podem ver estou um pouco confuso com estes dos Patterns.

Super normal, são confusos mesmo. Você já tentou ler a bibliografia recomendada?

Entusiasta Java Membro desde: 01/06/2009 17:56:34 Mensagens: 18 Offline

Olá, Philip e qual bibliografia seria recomendada?

Valeu

Entusiasta Java Membro desde: 01/06/2009 17:56:34 Mensagens: 18 Offline

YvGa wrote:Outra coisa questionavel é o findByIsso findByAquilo. Existem algumas formas de se evitar isso, a mais simples com um map propriedade, valor de busca, que torna a interface do dao bem mais simples.

Interfaces normalmente parecem desnecessarias, mas normalmente somos nos que estamos pensando errado. Elas desacoplam completamente as classes clientes das implementacoes, se mesmo com o uso de interfaces elas continuam acopladas é porque estao sendo mal usadas.

Na verdade o que esta sobrando ai na sua aplicacao nao sao as interfaces, mas a factory dos daos. Use Spring e chute essa factory pra longe.

Olá, na verdade o findByIsso, findByAquilo, eu resolve com o findByExample do hibernate, onde passo objeto populado com os atributos que quero q ele busque. Desta forma, somente se for uma pesquisa bem específica, como por exemplo misturar um like, com um eq, junto com um group by, é que crio um metodo difirente no XXXDAo especifico;

ravisantos wrote:Olá, Philip e qual bibliografia seria recomendada?

Oi,

Por mim, esta: http://blog.fragmental.com.br/2008/05/20/trilha-de-livros-desenvolvedor/

Entusiasta Java Membro desde: 01/06/2009 17:56:34 Mensagens: 18 Offline

pcalcado wrote:

ravisantos wrote:Olá, Philip e qual bibliografia seria recomendada?

Oi,

Por mim, esta: http://blog.fragmental.com.br/2008/05/20/trilha-de-livros-desenvolvedor/

Olá Philip, obrigado pela lista. Excelentes livros, porventura atualmente estou lendo o Fundamentals of object-oriented design in UML, e estou gostando muito.

Mas pelo que li em outros lugares, um repositorio, só faria sentido caso estivesse usando DDD, ou pelo menos um Domain Model, tentando "blindar" a cama de negócios, do contrário, acho que o Dao se encaixa melhor.

Entusiasta Java Membro desde: 01/06/2009 17:56:34 Mensagens: 18 Offline

pcalcado wrote:

ravisantos wrote:Olá, Philip e qual bibliografia seria recomendada?

Oi,

Por mim, esta: http://blog.fragmental.com.br/2008/05/20/trilha-de-livros-desenvolvedor/

Philip, muitos questionam o uso do Repository com o Dao ou seja o Repositorio sendo um interface para o Dao. Dizem que o dao neste caso nao faz sentido bastando ter por composicao dentro do repositorio, uma Session ou EntityManager.

O que você pensa desta abordagem?

ravisantos wrote:
Philip, muitos questionam o uso do Repository com o Dao ou seja o Repositorio sendo um interface para o Dao. Dizem que o dao neste caso nao faz sentido bastando ter por composicao dentro do repositorio, uma Session ou EntityManager.

O que você pensa desta abordagem?

Desde que não haja dependência nenhuma da as classes da Camada de Negócio para Hibernate/JPA/etc. Não há qualquer problema. O que geralmente eu tenho hoje em dia é um UsuarioRepositorio como interface que é implementado por um HibernateUsuarioRepositorio. O primeiro é da Camada de Negócios e o último da Persistência.

rponte wrote:Não faz muito sentido para a maioria dos casos se ter um DAO quando se está trabalhando com um framework ORM como JPA/Hibernate.

Eu discordo.
Não necessariamente um DAO, mas acho válido uma camada que abstraia a persistência das minhas entidades de negócio.(DAO, Repository, DataMapper, etc)

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