Pessoal, estava eu googlando, quando encontrei um artigo interessante sobre a necessidade real de utilização de DAOs em uma aplicação onde é possível de utilizar JPA.
http://www.infoq.com/news/2007/09/jpa-dao
Na opinião de vocês, o DAO teria que ser mantido, já que tem a função de des-acoplamento do meio de persistência (RDB,XML,OODB,Flat file…) e manter a coesão do domínio.
Ou simplesmente isso não é tão importante em determinadas aplicações, já que nem sempre se preve a alteração do meio de persistência e já que existe muita “OO porca” por ai :?, essa pequena perda de coesão seria aceitável ?
Eu tenho lá minhas dúvidas em utilizar DAOs em todas as situações, e vocês como vêem essa camada ?
Tudo o que desenvolvo usando persistência (e é pouca coisa) eu incluo DAOs. Afinal, como você pode dizer que o software nunca vai precisar de tal coisa? Acho que fazer DAOs “respeita” um dos conceitos de Orientação a Objetos e leva a um bom design.
Claro que muitas vezes (principalmente no começo), a codificação demora e o sistema aparenta ficar mais complexo. Mas com o tempo, acredito ser uma opção melhor.
Abraço.
"
Hum…
O JPA ao meu ver, já está servindo de camada de abstração para uma tecnologia de persistência, Hibernate, IBATS, JDO, JDBC etc…
Seria realmente necessário inserir outra camada em cima desse cara?
E pior, geralmente uma camada muito mais pobre!
Abraços.
"
Como vc disse, já exite muita oo porca por aí…
Isso já é um excelente motivo para usar não só o DAO, mas outros padrões que mantém organizada e desacoplada a arquitetura! Procurar implementar um projeto voltado a interfaces e não a implementações concretas e assim por diante…
Claro que não da pra querer sair metendo padrão em tudo, que aí complica ao invés de ajudar…
[]'s
Eu acho totalmente válido manter o código de acesso a dados em um DAO. Seja ele com JPA, Hibernate, JDBC, etc…
Ao meu ver é importante para que seu código de negócio esteja desacoplado da camada de persistência. Lembra da história das janelas quebradas???
Fala primo.
O problema que vejo nos DAOs é que o mesmo é extremamente inflexível e pobre.
E ae mohamed…
Por que inflexível???
Sobre ser pobre… eu prefiro deixar a criação dos HQL’s ou SQL’s em um componente separado (DAO). Sem DAO (ou qualquer outro nome), onde você colocaria este tipo de código???
Concordo com o marcosalex. A utilização ou não de DAOs depende da complexidade da aplicação. Em aplicações mais simples que utilizam basicamente operações CRUD, não vejo problema algum em não utilizar DAOs, reduzindo a quantidade de código gerado. Nestas ocasiões, o DAO praticamente “delega” chamadas ao entity manager.
Qual a utilidade do DAO ?
R : Abstrair a fonte de dados, para que futuras alterações não afetem a camada de negócio. (resumido)
Quais seriam essas futuras alterações ?
R : API de acesso de dados, mecanismo de persistência, alteração de fonte de dados, etc…
JPA não realiza as abstração necessária ?
R : Não, mas a maioria em se tratando de RDBMS.
E se eu quiser ter uma segurança de não ficar apenas amarrado ao RDBMS e utilizar um XML ou File flat para persistencia ?
R : Utiliza JDO, que inclusive encapsula um JPA.
Ou seja, se já existem padrões para essas abstrações, para que utilizar DAOs as cegas (usar por usar) ?
Concordo também que isso depende muito do projeto em questão.
Bom, em um projeto que fiz que busquei ser o mais desacoplado e OO possível, além de criar DAOs, usei interfaces em conjunto com os padrões AbstractFactory e Factory para criar meus DAOs independete da implementação escolhida… Por exemplo se eu quisse mudar no JPA para salvar tudo em txt, precisaria apenas criar uma implementação para a interface do DAO com os métodos de salvar no txt, e falar que a partir de agora a factory me retornaria esses DAOs…
Em outros projetos fiz apenas a implementação do DAO, sem uso de interfaces ou factory, o que é o mínimo que eu faria.
Com exceção dos factories, essa camada comum para os DAOs poderia ser implementada com o JDO.
http://java.sun.com/jdo/index.jsp
Apesar de eu achar realmente que é muito difícil um projeto deixar de usar um RDBMS para utilizar XMLs ou Arquivos.