Bem, quanto aos DAOs, eu acho que eles são úteis pra isolar o Hibernate, mantendo tudo quanto é HQL e Criteria em um só lugar, e não espalhado pelo sistema. Isso não requer interfaces (apesar delas serem úteis pra criar mocks de teste) e não aumenta estrondosamente a quantidade de código, apenas move um código que deveria existir de uma forma ou de outra. (obs.: mocks de DAOs são mesmo necessários, sendo que podemos simplesmente usar algum banco em memória, como o HSQLDB?)

A coisa fica complicada é quando alguém quer criar uma *abstração* sobre o Hibernate, fazendo de conta que tanto faz ser Hibernate, JDBC, iBatis, LDAP, XML, ou qualquer outra coisa. Das duas uma: ou ele nivela por baixo e perde as vantagens de se usar o framework, ou ele usa as features avançadas e torna a ‘abstração’ totalmente amarrada com o Hibernate. E por ‘amarrada’ não quero dizer que ele vá usar HQL diretamente (já que isto está ‘abstraído’), mas sim o lazy-loading, cache e relacionamentos, só pra citar o básico.

Então, já que é pra usar Hibernate, USE-O, não minta pra si mesmo. Mas não precisa espalhar imports org.hibernate.* por todo o código pra fazer isso :)

Quanto ao HibernateTemplate do Spring, ele não tenta abstrair o Hibernate, apenas facilita o seu uso. Mas claro, como o Hibernate já é uma abstração sobre JDBC, e tem uma API razoavelmente simples, um outro facilitador talvez seja desnecessário. (Já o JdbcTemplate é muitíssimo útil :))

Acho que estamos falando a mesma coisa de formas diferentes. Quando eu falei sobre as chamadas a JDBC direto ou geração de XMLs, estava falando sobre novas implementações de seus DAOs, convivendo pacificamente com as implementações sobre o Hibernate / Toplink / iBatis…

Enfim, o que eu quero dizer é: não concordo com nada que não implemente a interface DAO (ou similares) usando Session / EntityManager.

Rubem, o Michael não tá falando em não usar o DAO! Interfacear o DAO é interessante para os testes sim! mas além disso você já está pagando um preço caro…

É justamente aí que talvez DAOs tenham uma utilidade que não seja necessariamente abstrair O banco de dados mas sim o acesso aos dados. É mais sobre Separation of Concerns do que sobre ter que mudar o tipo de repositorio.

valeuz…

No caso o DAO por exemplo, eu prefiro usar DAOs, com interface, abstraido e tudo mais. A questão não é só “e se a gente trocar de banco” mas também da testabilidade e da manutenabilidade (existe essa palavra?) da aplicação. Se você colocar no teu objeto de negócio a session direto do Hibernate, como você vai fazer os seus testes unitários? E se der um problema? Será que é no
DAO ou na classe de negócio? Com o código isolado, fica *bem* mais fácil encontrar o problema, bem mais fácil de dar manutenção, bem mais fácil de reaproveitar.

É claro que para uma aplicação simples, sem muitas pretenções, pode-se usar a session direto, ou até a Connection, sem Hibernate mesmo.

Mas para aplicações mais sérias, com finders mais complexos, isolar num DAO vai deixar o código mais testável, mais fácil de manter e mais organizado.

Na prática, o ideal é modificar esses casos de exceção a medida que surgem e não o contrário. Além disso, não entendi muito bem como que a otimização JDBC geraria outra implementação DAO ao invés de substitui-la.

Aí não temos mais “um monte” de interfaces no código. Apenas a interface DAO e suas filhas (o que eu tb discordo um pouco, como você pode ver aqui.

Eu discordo no ponto de não abstrair o framework de ORM. Acho útil abstrair não para trocar fácil de banco de dados, mas sim para otimizações que possam ser necessárias. É comum acontecerem casos que você precisa abrir mão das vantagens do ORM e acessar o banco direto via jdbc, ou persistir o objeto em um lugar diferente (num arquivo xml, por exemplo) porque o banco é legado e você não pode criar outra tabela).

Além disso, pelo menos para mim, na prática abstrair o ORM não têm sido muito trabalhoso tampouco tem limitado o que posso fazer com ele.