Usar ou não DAO nos tempos do JPA?

Recentemente fui questionado sobre os design patterns a serem usados no desenvolvimento de aplicações Web com JSF e JPA. As seguintes perguntas foram feitas:

• Pensamos em usar um Mediator para evitar acesso direto ao JPA dentro do Seam Component. Este padrão é o melhor a ser adotado?
• Tem mais algum design pattern que devemos usar explicitamente? Já estamos utilizando DAO, para separar os métodos de acesso ao JPA.

Pensando sobre o assunto, cheguei às seguintes idéias.

Vejo que nos tempos de JPA, evitar o acesso direto ao JPA a partir da camada controller ou até mesmo da camada model (via serviços, ou melhor, façades) não é mais necessário. O uso de um mediator ou DAO para encapsular os códigos de persistência estão saindo de moda considerando que a interface desses objetos é praticamente a mesma do EntityManager. Ou seja, se adicionarmos essa camada, vemos que praticamente é uma cópia e passagem direta de chamadas de uma camada para outra sem um valor agregado significativo. Pode até ser que compense por impor uma interface de DAO com tipagem baseada nas entidades, considerando que JPA não usa generics ainda.

No tempo do JDBC, onde tínhamos infinitas linhas de código para persistência de cada entidade, o DAO ou o encapsulamento de códigos de persistência tinha uma valor enorme para o reuso e manutenibilidade. No tempo do Hibernate, o uso do DAO ainda podia ser justificado considerando que a API do Hibernate não era considerada um padrão. Então seria interessante manter o acesso ao BD encapsulado para possíveis trocas de "provider". Mas, já nesse tempo começamos a perceber que os DAOs não tinham muito código por conta do Hibernate generalizar o acesso ao DB através de reflection e dialect. Mas, agora nesses tempos de JPA a API é padrão, já encapsula a independência do provider, já oference um processo simplificado de configuração e uma API genérica para todas as entidades via reflection, além de ter o mesmo efeito do Hibernate na redução drástica de códigos nos DAO. Uma camada específica de DAO para persistência em banco de dados via JPA perde sentido. Contudo, o DAO ainda é interessante para outros meios de persistência, e até mesmo DB se JPA não for usado.

Portanto, eu recomendo usar o JPA (EntityManager) diretamente na camada controller (MBs clássicos ou seam components como MBs) ou na camada model (seam components como façades ou business services). Daí podemos nos beneficiar da simplificação proposta pelo Java EE ao promover o IoC/DI através da anotação @PersistenceContext ou da proposta do Seam ao promocer o IoC/DI através da anotação @In. Então, a dúvida agora reside em fazer ou não uma camada model para delegar a persistência da entidade a esta camada! Confesso que é uma dúvida interessante de responder e que pode ser adiada para o momento de modelagem de cada arquiterura que realizarmos.

Muitos já me questionaram sobre usar ou não DAO nesses tempos de JPA. Agora pude compartilhar um pouco do que penso sobre esse assunto ... Qualquer contra-posição, adoraria discutir ...

Uma discussão acalorada foi resumida num post do site InfoQ pelo Craig Wickesser "Has JPA Killed the DAO?" com argumentos contra e a favor do DAO com JPA.