DAO genérico

Você pode fazer algo como

if (objD instanceof Cliente) 
      {
            ClienteDAO alguma coisa
       }
   if (objID instanceof Emprestimo)
      {
            EmprestimoDAO alguma coisa
      }

Que tal isso :

public interface DaoInterface<T>{

	
	public boolean insert(T objD);
	
	public boolean update(T objD);

	public boolean remove(T objD);

	public T findByKey(T objD);

	public Collection<T> findHQL(String query);
}

Mais informações a respeito vide :
http://blog.caelum.com.br/2006/10/29/brincando-com-generics-o-bizarregenericdao/
http://blog.caelum.com.br/2006/08/26/ei-como-e-o-seu-dao-ele-e-tao-abstraido-quanto-o-meu/

[]'s

A do Marcio é ainda melhor!

O mito do DAO genérico. Para que fazer isso se existe o Hibernate?
Até o pessoal do .NET tem algo mais esperto que um DAO genérico, que é o tal do LINQ for SQL.

nossa kra vlw mesmo ficou muito bom...um dao pra todo mundo agora!!!!! =D
mas to com umas duvidas

1 -pq eu tenho que colocar esse na frente da classe??
2- o que é exatamente esse?? é da sintaxe do generic???

public class Dao<T> {

}

mas vlw mesmo ficou muito bom.

nao entendi thingol. estou usando o hiberntate, mas porque nao precisaria do DAO??

malz a ignorancia, pq sou novo em java e agora que estou comecando a usar patterns e talz.

O DAO é um famoso “design pattern”, mas como todo bom “design pattern”, não é algo que deva ser seguido a ferro e fogo. Se você pode usar uma tecnologia que dispense isso (como é o caso do Hibernate), use-a. No seu caso, você está misturando Hibernate e DAOs, e ainda fazendo um “DAO genérico”. Acho que no caso do Hibernate só o misturaria com DAOs se eu tivesse de mexer num sistema já existente, que é movido a DAOs.

entendi. o que vc quiz dizer agora =)

Vanderbill:

tenho a seguinte interface

public interface DaoInterface{

	
	public boolean insert(ObjetoDesejado objD);
	
	public boolean update(ObjetoDesejado objD);

	public boolean remove(ObjetoDesejado objD);

	public ObjetoDesejado findByKey(ObjetoDesejado objD);

	public Collection<ObjetoDesejado> findHQL(String query);
}

entao vms supor q eu tenha 2 classes DAO(ClienteDao, EmprestimoDao) que implementam essa interface.
como fazer para que o objeto desejado seja Cliente quando estiver usando a ClienteDao, ou que ele seja Emprestimo quando estiver usando EmprestimoDao.

desde ja agradeco a atenção, caso minha duvida nao esteja clara me avisem.

vlws! t+!

O thingol quis dizer que ao invés de você ter mais uma camada somente para o hibernate e o seu dao, você pode simplesmente efetuar as chamadas ao Hibernate da sua classe de negócio.

Ex.:

public class ClienteService {

public void salvarCliente(Cliente obj) {
    HibernateUtil.getSession().save(obj);
}

}

[]'s

Se o DAO é genérico então sua solução deve ser genérica certo?

:idea: GENERICS :idea:

Ah, eu não acho legal chamar código do Hibernate diretamente das classes de negócio… o DAO ajuda a isolar o código do Hibernate do código da sua aplicação… Acho mais recomendável, utilizar uma interface conveniente para sua camada de persistência (DAO) e implementar essa interface do jeito que quiser (usando Hibernate ou nao).

Seguem alguns artigos sobre o assunto:

abraços

zakim desculpe mas nao entendi o que vc quiz dizer poderia ser mais claro??

e eu concordo com o agazola, classes de negocio devem ter somente ter getters/setters e seu construtor. isto na minha opniao =)

Esse artigo fala um pouco sobre isso: http://fragmental.com.br/wiki/index.php?title=Fantoches

Eu gosto da definição do PoEAA (p. 134) que separa “lógica de negócio” em duas:

• lógica de domínio: componentes que tem a ver apenas com o domínio do problema, implementam as regras de negócio
• lógica de aplicação componentes que tem a ver com a infra-estrutura da aplicação, com a tecnologia

No caso, a camada de serviços e os daos se encaixariam na lógica de aplicação…

abraços

Leia e aprenda a utilizar generics, com certeza a melhor opção para uma genericDao! (Estou sendo intuitivo).

Com generics vc decide quem vai ser o objeto da parada de acordo com sua subclasse.

interface GenericDao(){}

abstract class  AbstractDao implements GenericDao{
//aqui vc implementa os metodos que são comuns para todas as possiveis subclasses utilizando ainda generics

}

final class ClienteDao extends AbstractDao{

// aqui vc completa os metodos abstratos e implementa os metodos restantes do GenericDao que não foram
//implementados pelo AbstractDao
}

A vantagem do generics é que vc vai evitar de ficar reescrevendo métodos somente para mudar o tipo de retorno ou de parametro!

a estrutura que te passei, é bacana para flexibilizar as soluções tanto com generics como qualquer outra escolha que vc possa escolher.

Ok. Não vamos entrar numa discussão desnecessária. Existem milhares de threads neste fórum com muitas páginas de idéias do tipo, uso minha camada de persistencia isolada da de negócio, mesmo usando hibernate ou não…

Como lí ontem no blog do Mister M, o uso de um monte de interfaces para a camada Dao, na maioria das vezes, é simplesmente para evitar um futuro retrabalho caso mude o banco de dados, e sabemos que no mundo real, isso quase nunca acontece.

Como o hibernate já é uma implementação do JPA e te fornece muitos métodos prontos para as transações com o BD, o uso de uma camada Dao pode ser reconsiderado.

É a minha humilde opinião. Até hoje tenho mtos sistemas usando a camada Dao.

[]'s

agazola:

Ah, eu não acho legal chamar código do Hibernate diretamente das classes de negócio… o DAO ajuda a isolar o código do Hibernate do código da sua aplicação…

Se vc quer isolar o hibernate do resto da aplicação existem muitas maneiras de o fazer, mas o DAO não é uma delas. Use o repositorio ou um serviço para isso. O objetivo do DAO é poder mudar a persistencia da aplicação de forma transparente. Se vc está usando Hibernate isso nunca será possivel. Logo, não ha razão para ter o DAO.

Implemente então um DAO para uma classe à sua escolha usando Hibernate.
Depois implemente outro DAO com a mesma interface que o primeiro para a mesma classe, mas que use apenas um List na memorica como banco de dados. Experimente. Se o seu DAO foi feito com hibernate a propabilidade maior é que ele não seja compativel com a outra forma de implementar. O exemplo dado neste topico, por exemplo, não é.