Foi o que acabou acontecendo, eliminamos a implementação do DAO Genérico e, utilizamos somente a interface genérica que passou a ser implementada por cada DAO especifico.

Um motivo disso foi que, em alguns momentos, as informações eram persistidas em arquivos. O fato de invocar o método persist do DAOGenérico sempre, havia momentos em que deveria ser invocado o metódo persist do DAOEspecifico. Isso iria acabar causando confusão para o desenvolvedor. Além de ficar uma arquitetura “confusa”.

Eliminamos a palavra/conceito de DAO e adotamos a de Repository

É uma opção válida. O que costuma acontecer é que o DAO genérico começa a não servir para muita coisa, pois, mesmo em situações simples como o persist, começamos a colocar outros detalhes de persistência dentro desses métodos, relativos a “lógica de persistência”. A partir desse momento o dao generico nao ajuda muito, nao importa se fizermos elegantemente via injecao de dependencias e sem heranca.

Porque vocês não fazem assim? O que tem de errado nesse conceito?

Obrigado

interface Ipersist {
void persist(T t);
}

interface Iremove {
void remove(T t);
}

interface Isearch {
T search(Serializable id);
}

Att.

* Normalmente uma classe possui muito mais metodos relacinados a dados que um CRUD.
* Agora seu implementador de código pode excluir qualquer coisa acesando diretamente a persistência, isso que dizer que seu código foi desenvolvido para 1 cabeça dar manutenção. Exemplo: excluir uma empresa da base (se não houver Constraint Restrict).
* Não economizou código, pelo contrario, escreveu mais. Praticamente terá que implementar muitos métodos do objeto session da API Hibernate.

*Nenhum isolamento de pacote…

Não existe uma DAO generico no proprio Hibernate? Porque?

Eu utilizo Top Link e gostaria muito de ver um exemplo DAO. Estou desenvolvendo um mas estou tendo alguns probleminhas pois só encontrei exemplos utilizando Hibernate.