Vamos discutir sobre DAOs genericos!!!

Pessoal andei pesquisando por ae sobre daos genericos, e não gostei muito do que vi, ou nao entendi muito bem.

Bom o exemplo em questão é este que colo aqui:
Feito pelo ralphsilver neste tópico: http://www.guj.com.br/posts/list/140871.java

Minha idéia de dao generico é que ele seja generico e faça tudo pra mim, com qualquer tipo de object que eu envie pra ele.
Então nao poderiamos parar no BaseDaoImpl???

Porque é que eu preciso ir alem e ter mais uma interface e uma classe por ex: PessoaDao e PessoaDaoImpl??

Estou enferrujado e nao estou entendendo este conceito.

E outra imaginem eu com um CRUD de 100 Entities, neste caso vou precisar criar + 100 interfaces Dao e + 100 classes DaoImpl, fala sério 300 arquivos sendo que poderiam ser 100 e o BaseDaoImpl dar conta de fazer qualquer coisa com eles?? Na verdade este BaseDaoImpl ja consegue fazer tudo, o que nao entendo é porque ter mais uma interface e uma classe para cada entity.

Alguem tem uma outra versão de Daos genericos ai pra oferecer??

classe abstrata DAOImpl:

import java.util.List;

import javax.persistence.EntityManager;
import javax.persistence.EntityTransaction;

import br.edu.unianhanguera.plt.dao.BaseDAO;

public abstract class BaseDAOImpl<T> implements BaseDAO<T> {
	protected EntityManager em = null;
		
	@Override
	public abstract List<T> findAll() throws Exception;
	@Override
	public abstract T load(Object obj) throws Exception;

@Override
	public T persist(T object) throws Exception {
		EntityTransaction transaction = em.getTransaction();
		transaction.begin();
		try{
			em.persist(object);
			transaction.commit();
			return object;	
		}catch(Exception e){
			transaction.rollback();
			throw e;
		}
	}

@Override
	public List<T> persist(List<T> list) throws Exception {
		EntityTransaction transaction = em.getTransaction();
		transaction.begin();
		try{
			for(T object:list)
				em.persist(object);
			transaction.commit();
			return list;	
		}catch(Exception e){
			transaction.rollback();
			throw e;
		}
	}

@Override
	public T remove(T object) throws Exception {
		EntityTransaction transaction = em.getTransaction();
		transaction.begin();
		try{
			em.remove(object);
			transaction.commit();
			return object;	
		}catch(Exception e){
			transaction.rollback();
			throw e;
		}
	}

@Override
	public List<T> remove(List<T> list) throws Exception {
		EntityTransaction transaction = em.getTransaction();
		transaction.begin();
		try{
			for(T object:list)
				em.remove(object);
			transaction.commit();
			return list;	
		}catch(Exception e){
			transaction.rollback();
			throw e;
		}
	}

@Override
	public T update(T object) throws Exception {
		EntityTransaction transaction = em.getTransaction();
		transaction.begin();
		try{
			em.merge(object);
			transaction.commit();
			return object;	
		}catch(Exception e){
			transaction.rollback();
			throw e;
		}
	}

@Override
	public List<T> update(List<T> list) throws Exception {
		EntityTransaction transaction = em.getTransaction();
		transaction.begin();
		try{
			for(T object:list)
				em.merge(object);
			transaction.commit();
			return list;	
		}catch(Exception e){
			transaction.rollback();
			throw e;
		}
	}

}

quando eu preciso criar uma classe (Pessoa por exemplo) eu a interface DAO:

e o DAOImpl

ola Fred. Excelente pergunta! Algumas opinioes minhas:

- para 300 classes de modelo, voce nao precisa de 300 DAOs: voce pode (e deve) agrupar os que fizerem sentido.
- nao pegue catch em Exception: o elhor é fazer o tratamento correto de PersistenceException e deixar um finally bem escrito
- cuidado com as transacoes : é melhor deixar o controla transacional fora, pois ai voce pode agrupar operacoes do dao. caso contrario voce tera problemas para criar uma transacao que insira dois tipos de objetos diferentes, por exemplo
- eu hoje em dia ja nao gosto de dao generico, ainda mais para usar com heranca: traz muita dor de cabeca, e se voce for ver, sem esse codigo transacional, ele resolve pouca coisa. e a melhor maneira sempre é compor em vez de herdar!

abracos

Quanto ao fato de criar cada uma classe DAO para cada entidade não tem como fugir,mas realmente não faz sentido ter uma interface para cada entidade, então apenas não a implemente.

Nesse caso que vc postou, não bastaria fazer assim:

Não sei se precisa criar uma interface para Pessoa, acho de mais.

Paulo Silveira wrote:ola Fred. Excelente pergunta! Algumas opinioes minhas:

- para 300 classes de modelo, voce nao precisa de 300 DAOs: voce pode (e deve) agrupar os que fizerem sentido.
- nao pegue catch em Exception: o elhor é fazer o tratamento correto de PersistenceException e deixar um finally bem escrito
- cuidado com as transacoes : é melhor deixar o controla transacional fora, pois ai voce pode agrupar operacoes do dao. caso contrario voce tera problemas para criar uma transacao que insira dois tipos de objetos diferentes, por exemplo
- eu hoje em dia ja nao gosto de dao generico, ainda mais para usar com heranca: traz muita dor de cabeca, e se voce for ver, sem esse codigo transacional, ele resolve pouca coisa. e a melhor maneira sempre é compor em vez de herdar!

abracos

Opa Paulo blz.

Então, sobre as exceptions e etc no exemplo postado, apenas copiei e colei do outro topico para sevir de base a pergunta, este não é de fato o meu codigo, ainda estou atraz de respostas

Mas seus conselhos estão anotados.

Aproveitando sua presença no topico, estou justamento começando um projeto com vRaptor, e estou atraz da opção mais elegante e menos trabalhosa para a camada de persistencia, tirando proveito da injeção de dependencia, interceptors e tudo mais que o vRaptor tem a oferecer.

Certo, então sobre o exemplo citado voce acha que eu deveria parar no BaseDaoImpl, e então fazer daos para certos grupos de entities, seria isto?

E ainda sobre compor ai inves de herdar, me corriga se entendi seu ponto errado, eu teria então o BaseDaoImpl concreto, e um outro tipo de dao +- assim:

E ainda por ultimo, voce diz que não gosta de dao generico, qual seria sua abordagem para a persistencia hoje em dia, é disto que estou atras, de uma abordagem mais contemporania, usando o que a OO e o vRaptor tem a nos oferecer.

Grato.

romarcio wrote:Nesse caso que vc postou, não bastaria fazer assim:

public class PessoaDAO extends BaseDAOImpl<PessoaEntity>

Não sei se precisa criar uma interface para Pessoa, acho de mais.

Ao meu ver sim, mas mesmo neste exemplo eu ainda teria 100 classes modelos e outras 100 dao, claro que as operações basicas ja estariam prontas.

Porem é justamente isto que estou tentando entender, em minhas pesquisas no google, a maioria dos exemplos que encontro estão sempre deste jeito, queria saber o porque. Sera que um cara fez uma vez e o resto saiu copiando e postando

fredferrao wrote:

romarcio wrote:Nesse caso que vc postou, não bastaria fazer assim:

public class PessoaDAO extends BaseDAOImpl<PessoaEntity>

Não sei se precisa criar uma interface para Pessoa, acho de mais.

Ao meu ver sim, mas mesmo neste exemplo eu ainda teria 100 classes modelos e outras 100 dao, claro que as operações basicas ja estariam prontas.

Porem é justamente isto que estou tentando entender, em minhas pesquisas no google, a maioria dos exemplos que encontro estão sempre deste jeito, queria saber o porque. Sera que um cara fez uma vez e o resto saiu copiando e postando

Sim, mas disso acho que vc nem deve tentar fugir, pq é a Orientação Objetos.

A classe PessoaEntity, seria apenas a entidade com getters, setters e a classe PessoaDAO teria outra função que seria a realização das consultas e tudo mais envolvendo banco de dados.
O padrão é não mistura-las mesmo.

JavaEvangelist Membro desde: 21/11/2006 20:48:46 Mensagens: 311 Offline

Criar as interfaces e DAO's para cada entidade geralmente é feito para se ganhar flexibilidade.

Se você usa o mesmo DAO genérico para todas as entidades, está assumindo que a persistência será igual para todas as entidades, o que nem sempre é verdade.

Em algum momento você pode querer tratar especificidades de cada entidade, e se tudo estiver desacoplado desde o início isso se torna mais fácil, principalmente se você estiver tratando com uma quantidade grande de entidades como você especulou.

Se o problema for escrever tantos arquivos, bom, se você tem o seu ambiente, não custa nada perder alguns minutos criando um pequeno gerador de código pra isso.

romarcio wrote:

fredferrao wrote:

romarcio wrote:Nesse caso que vc postou, não bastaria fazer assim:

public class PessoaDAO extends BaseDAOImpl<PessoaEntity>

Não sei se precisa criar uma interface para Pessoa, acho de mais.

Ao meu ver sim, mas mesmo neste exemplo eu ainda teria 100 classes modelos e outras 100 dao, claro que as operações basicas ja estariam prontas.

Porem é justamente isto que estou tentando entender, em minhas pesquisas no google, a maioria dos exemplos que encontro estão sempre deste jeito, queria saber o porque. Sera que um cara fez uma vez e o resto saiu copiando e postando

Sim, mas disso acho que vc nem deve tentar fugir, pq é a Orientação Objetos.

A classe PessoaEntity, seria apenas a entidade com getters, setters e a classe PessoaDAO teria outra função que seria a realização das consultas e tudo mais envolvendo banco de dados.
O padrão é não mistura-las mesmo.

Com certeza voce esta certo, PessoaEntity é a classe burra com getters e setters e jpa annotation, nao foi isto que quis dizer.

Eu esta pensando em algo como DaoGenericoParaQualquerEntity + PessoaEntity, ClienteEntity, CidadeEntity, etc, quando digo economizar é disto que estou falando, fazer apenas um DAO que sirva a todos.

juliofsn wrote:Criar as interfaces e DAO's para cada entidade geralmente é feito para se ganhar flexibilidade.

Se você usa o mesmo DAO genérico para todas as entidades, está assumindo que a persistência será igual para todas as entidades, o que nem sempre é verdade.

Em algum momento você pode querer tratar especificidades de cada entidade, e se tudo estiver desacoplado desde o início isso se torna mais fácil, principalmente se você estiver tratando com uma quantidade grande de entidades como você especulou.

Se o problema for escrever tantos arquivos, bom, se você tem o seu ambiente, não custa nada perder alguns minutos criando um pequeno gerador de código pra isso.

Sim, eu pensei nisso. Mas neste caso eu faria apenas se fosse necessario, não? Se um ou outro precisasse de tratamento especial ai sim caberia uma herança e tals.

This message was edited 1 time. Last update was at 20/08/2010 10:08:35

fredferrao wrote:Se um ou outro precisasse de tratamento especial ai sim caberia uma herança e tals.

Mas aí, imagine se você tiver que tratar a classe Pessoa, você teria que criar o DAO para Pessoa e na camada acima, mudar a classe que utiliza o DAO genérico para fazer operações com Pessoa, trocando pelo DAO específico que você criou.

Se você já tem um DAO para cada entidade, você só teria que mudar o DAO de Pessoa.

juliofsn wrote:

fredferrao wrote:Se um ou outro precisasse de tratamento especial ai sim caberia uma herança e tals.

Mas aí, imagine se você tiver que tratar a classe Pessoa, você teria que criar o DAO para Pessoa e na camada acima, mudar a classe que utiliza o DAO genérico para fazer operações com Pessoa, trocando pelo DAO específico que você criou.

Se você já tem um DAO para cada entidade, você só teria que mudar o DAO de Pessoa.

Realmente, se houverem novos metodos que o "controller" por exemplo teria que chamar, ia ter que sair refatorando, mas se os metodos continuam os mesmos e mudou apenas a logica do "persist" por exemplo, o polimorfismo daria conta do recado.

Oi fredFerrao,

Estou entendendo que o ponto que está gerando as dúvidas é o fato de que o DAO está diretamente ligado adiferenciado de banco de dados e que o "DAO generico" na verdade precisa "saber" qual é o TIPO de objeto que será persistido, ou seja, na verdade talvez não tenha nada de generico assim, já que ele precisa saber os tipos dos objetos.

A interface específica de cada entidade acaba fazendo parte do padrão de solução (DAO), caso vc tenha mais de um tipo de banco de dados vc "força" que a implementação seja garantida seguindo a especificação da interface.

Resumindo...infelizmente a coisa envolve muito código, acredito que o uso de um bd orientado a objetos estas coisas desapareçam completamente.

P.S Desculpem se não entendi direito o tópico.

flws

fantomas wrote:Oi fredFerrao,

Estou entendendo que o ponto que está gerando as dúvidas é o fato de que o DAO está diretamente ligado adiferenciado de banco de dados e que o "DAO generico" na verdade precisa "saber" qual é o TIPO de objeto que será persistido, ou seja, na verdade talvez não tenha nada de generico assim, já que ele precisa saber os tipos dos objetos.

A interface específica de cada entidade acaba fazendo parte do padrão de solução (DAO), caso vc tenha mais de um tipo de banco de dados vc "força" que a implementação seja garantida seguindo a especificação da interface.

Resumindo...infelizmente a coisa envolve muito código, acredito que o uso de um bd orientado a objetos estas coisas desapareçam completamente.

P.S Desculpem se não entendi direito o tópico.

flws

O que estavamos discutindo, é a necessidade dos dois ultimos, ex: PessoaDao e PessoaDaoImpl, que como voce disse acaba fazendo parte da solucao(DAO).

Sobre os bancos de dados especificos, creio que não entram no mérito da discussão, pois levando-se em conta que se esta usando JPA, não haverá implementações especificas para cada BD.

Entendi...

Acredito que ao utilizar a JPA você tenha condições de eliminar ao menos a interface (PessoaDao) porem a classe PessoaDaoImpl (teriamos que mudar o nome dela) teria que continuar por causa do tipo da entidade que teriamos que informar ao mecanismo ORM ( entityManager.find(objectClass, id) ) sem falar do local dos algoritmos de manipulação dos objetos especificos daquela entidade.

Outro detalhe em relação a interface é que: se voce estiver utilizando o spring será sempre aconselhado a utilizar uma interface ao invés de uma implementação ao desenvolver suas classes e descreve-las nos seus (do spring) xmls.

flws

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