No more DAO’s
Monday, June 8th, 2009Um dos padrões de projetos mais conhecidos e mais utilizados ainda hoje é o DAO (Data Access Object). Padrão este que teve um papel fundamental há muitos anos, e que ainda hoje em determinados projetos de software desempenha muito bem seu trabalho. Contudo, isto não o torna, de maneira alguma, um padrão que todo arquiteto deveria implementar obrigatoriamente em qualquer aplicação.
Todo design pattern existe para resolver um problema comum de software, e não apenas para ser utilizado como uma receita de bolo em qualquer projeto. E com DAO não seria diferente. A finalidade do DAO é prover uma interface com operações para acesso a dados que abstraiam os detalhes do mecanismo de persistência (seja um banco de dados, ou não), ponto final.
Sua utilização há alguns 5 ou 6 anos atrás fazia todo sentido pois naquela época ainda erámos obrigados a trabalhar com JDBC puro e frameworks de persitência bem precários. Isto é, não tinhamos bons frameworks que abstraíssem de maneira satisfatória o acesso aos dados da aplicação (99% das vezes um banco de dados).
Por isso todo projeto de software daquela época implementava seu próprio DAO para evitar a mistura de código de negócios com código SQL (e mais alguns objetos de persistência), e assim diminuir o acoplamento entre as camadas (layers).
O problema é que hoje em dia com todos os consagrados frameworks para persistência ainda temos arquitetos implementando seu próprio DAO em todo e qualquer projeto de software que eles ponham as mãos. Mesmo que na arquitetura tenha-se adotado algum framework ORM (como JPA ou Hibernate) ainda assim temos os benditos DAO’s espalhados pela aplicação.
Sempre que vejo um projeto que adotou algum ORM (muitas vezes JPA) para persistência e me deparo com o famigerado DAO eu pergunto para o arquiteto da solução qual motivo o levou a colocar uma layer a mais na aplicação sobre o JPA. E como sempre recebo a seguinte resposta:
“Ah! para abstrair a camada de persistência. Assim se futuramente for necessário mudar de JPA para qualquer outra tecnologia, como JDBC puro, vai ser bem simples, pois bastaria criarmos outra implementação.”
Este tipo de argumento demonstra puro e simplesmente senso comum. Arquitetos que pensam assim pararam no tempo e não acompanharam a evolução das tecnologias ORM para plataforma Java. Outros mesmo atualizados seguem o senso comum. Pois é muito mais cômodo e simples para estas pessoas repetirem sempre a mesma “solução” em cada novo projeto do que se manterem atualizadas e avaliarem outras possíveis soluções.
O mais interessante disso tudo é que basicamente foi criada outra camada genérica para abstrair algo que por si só já é nossa abstração. O que estou querendo dizer, e que certamente foge ao senso comum, é que você não precisa de outra camada, o JPA já abstrai a persistência para você, ele além de muitas outras coisas já está atuando como nossa DAO layer.
A partir do momento que um arquiteto cria esta camada genérica ele está abrindo mão de features importantes de qualquer framework para persistência que ele venha a adotar. Todos os frameworks de persistência seguem filosofias e possuem features diferentes que agregam valor ao software de uma maneira ou de outra, mas que por termos esta camada de abstração não poderemos utiliza-las, caso contrário estaríamos detonando com a “portabilidade” da camada.
Quando adotamos um framework ORM como o JPA/Hibernate, não importa o motivo, já temos que ter em mente que nossa aplicação (principalmente o domain model) estará “mergulhada” nas features do framework, como anotações, contexto de persistência, lazy loading, dirty checking etc. Simplesmente mudar a implementação do DAO -como muitos acreditam- não garantirá que nossa aplicação continuará funcionando.
Ter esta camada extra de abstração (seu próprio DAO) pode matar o que de melhor seu framework ORM pode te oferecer, já que sua aplicação deverá funcionar independente da implementação utilizada. Por isso reflita se é melhor ter um full-ORM com um half-DAO do que ter um switchable-DAO com um half-ORM. Eu, particularmente, prefiro um full-ORM.
Antes que algum fanático por DAO venha aqui me crucificar, eu não tenho nada contra DAO layers, assim como também não acho que JPA tenha vindo para mata-lo. Mas acredito que este design pattern tem o seu lugar e deveria ser utilizado adequadamente, e não como uma camada obrigatória na aplicação.
Não existe uma receita de bolo para quando utilizar seu DAO genérico particular ou não. Cada projeto tem suas peculiaridades e estas devem ser analisadas com seus devidos cuidados. Mesmo eu achando que hoje em dia (a não ser que você esteja implementando o framework caseiro da sua empresa) não precisamos de tanta preocupação quanto a isso.
Para o caso especifico do JPA, utilize diretamente o EntityManager no lugar da sua abstraçao de DAO genérica, principalmente se você estiver implementando CRUDs, e utilize DAO’s onde for realmente necessário e fizer sentido. Bem mais simples, e bem menos artefatos na tua aplicação para manter.
Enfim, esse tipo de discussão sobre abstrair um framework ORM com uma camada DAO não vem de hoje, datam de meados de 2005 ou até menos. Meu conselho é que você não crie uma camada a mais para tentar abstrair o que por si só já é sua abstração. Trabalhe com o que o framework ORM te fornece, de preferência da melhor forma possível.
