JPA sem DAO

Houve uma peleja essa semana e gostaria de extender o assunto ao forum para ver a opinião de outras pessoas.

Você deixaria de lado suas classes DAO e utilizaria apenas o EntityManager injetado diretamente em suas classes de negócio?

O objetivo e colher mais opiniões, argumentos a favor e contra e quem sabe algum case.

IMHO, eu não faria isso, pelo simples fato (não menos importante) de ter separação entre camadas, e ter uma camada somente de acesso a dados.

JavaChild Membro desde: 14/11/2006 17:15:33 Mensagens: 149 Offline

Grande Igo,

Tá aí minha opinião:

As classes de negócio não devem criar esse mapeamento com o meio de armazenamento, esse papel de fazer o mapeamento dos objetos para qualquer tipo de armazenamento, seja tabelas, xml, csv, é do DAO. Os objetos de negocio não devem nem conhecer como os objetos estão sendo armazenados, e sim conhecer só repositorios. E o DAO ficar sendo a implementação de um Repositório.

[]'s

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Primeira verdade universal, até prova em contrário:
"DAO não é repositório."

Repositório, até onde eu sei, serve para buscar objetos, cujos parâmetros devem ser objetos do tipo Criteria, e só. Um DAO está mais para registro que repositório.

Segunda verdade universal, até prova em contrário:
"DAO e mapeamento OR não combinam, pois o primeiro cria contratos orientado a dados e o segundo, a objetos."

Em um mapeamento OR, só existem conceitos como objeto gerenciado e objeto não-gerenciado. Tentar mapear isso para um DAO clássico do tipo CRUD pode ser simplesmente uma dor de cabeça, uma vez que, uma possível implementação de DAO seria dar "detach" dos objetos a serem retornados e depois dar "merge" nos objetos recebidos como parâmetros (é até possível não fazer isso, mas isso implica que o DAO não é o único a fazer alteração de estado na base de dados). Não usar DAOs, deixar que o fim de um request e o começo de um outro façam o "detach" para você, e contar com recursos transacionais do Spring ou do EJB podem ser a melhor alternativa.

JavaChild Membro desde: 14/11/2006 17:15:33 Mensagens: 149 Offline

Nesse post tem uma boa explicação sobre DAO's e Repositorios.
http://blog.fragmental.com.br/2007/03/01/voce-pergunta-001-daos-e-repositorios/

[]'s

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Com certeza isso aqui também vai te ajudar a entender melhor a diferença entre repositórios e DAOs,
http://fragmental.tw/2007/11/29/repositories-misunderstandings/

JavaBaby Membro desde: 23/02/2005 10:58:35 Mensagens: 84 Offline

Já que vocês citaram o Shoes, repitam comigo

Repeat After Me: Repositories Aren?t DAOs
http://fragmental.tw/2008/04/25/repeat-after-me-repositories-arent-daos/

"Desta forma o DAO pode se tornar a implementação do Repositório."

Fonte: http://blog.fragmental.com.br/2007/03/01/voce-pergunta-001-daos-e-repositorios/

Opa! Primeiro post no fórum.

Eu não faria isso porque criaria uma dependência imensa com JPA e limitaria a padronização do uso de outras tecnologias ou frameworks para acesso a dados, como JDBC ou Hibernate. Se numa mesma aplicação há a possibilidade de se usar mais de uma opção, uma abstração como um DAO seria extremamente necessária.

Porque usar mais de uma alternativa? Vai depender do cenário. Se existir a necessidade de performance extrema, porque não usar JDBC com uma consulta nativa e bastante otimizada? O benefício pode valer a pena. Ou efetuar uma chamada a uma stored procedure? Aí é caso a caso.

Então, com relação ao post: sim, eu usaria uma abstração. Agora, se essa abstração seria DAO ou Repository, aí vai depender da moda que você vai querer seguir. Só digo uma coisa: DAO e Repository foram separados no parto. A diferença é semântica.

Sabe a diferença entre EMO e Punk?

assunto polemico!
eu nao aconselho, mas tem nomes fortes da comunidade que tem apoiado a ideia... acho que aquele adam bien é um deles

Higor / Igor,

Um outro ponto que eu deveria ter falado no post anterior que tem algo a ver com a minha opinião sobre necessidade de abstração.

Com relação a JPA, sinceramente, eu não entendi a idéia dos responsáveis, ou melhor eu entendi, só não quis acreditar. Lembro-me que quando JPA saiu, vi em algum lugar algo assim: "Pegamos as melhores idéias dos frameworks de persistência e criamos JPA".

Quando fui ver com mais cautela, percebi que JPA era (ainda é) uma versão enxugada do Hibernate e do TopLink. Os recursos mais úteis, como 'query by example', uma API semelhante à de Criteria ou Projections, simplesmente não existem.

Em algumas andanças por aí, percebi que as empresas começaram a adotar JPA, mas implementando dentro de casa a parte que faltava. Em casos piores, usavam o Hibernate como implementação, mas se recusavam a usar seus recursos.

Eu sei que JPA vai melhorar. Muitas coisas boas virão, mas um mecanismo desses não era novidade no mercado. Porque faze-lo tão pobre?

As perguntas são: porque usar JPA? Qual o benefício? Realizar horas de busca no Google? Consumir mais horas de projeto para fazer o mesmo?

Uma abstração poderia te fornecer a oportunidade de usar o mecanismo padrão, mas usando o melhor de cada implementação, quando for necessário. Quando JPA tiver pronta para o mercado, aí é só fazer alterações mínimas só naquela camada.

Acho que é isso.

[]'s

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

porque usar JPA

acredito que umas das vantagens seria o fato de estar usando uma especificação.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Eu bem que era a favor de eliminar os DAO's (e/ou Repositorio) por completo. Só acho que o JPA deixa um pouco a desejar neste sentido. JPA + CRUD está legal, só que queries ainda acaba deixando rastros de (hql/jpql) no seu domínio. Uma API de Criteria/Query Object integrado ao JPA tornaria essa discussão bem interessante, mas por enquanto, se o foco é ter um dominio bem legalzinho, sugiro utilizar DAO e/ou Repositorio.

Um dos motivos de eu antigamente apoiar a eliminação dos DAO's era simplesmente diminuir burocracia e dar uma alavancada na produtividade. Felizmente, hoje, com repositório (depois de entender melhor o padrão) consigo uma produtivadade ao meu ver bem melhor, já que não dependo de base de dados e persisto em memória. No final, repositorio é um padrão que deixa claro que não dependo nem um pouco da evolução do JPA.

rafaelmeireles wrote:

porque usar JPA

acredito que umas das vantagens seria o fato de estar usando uma especificação.

Rafael, você está certo, mas isso não deveria ser suficiente para adotar uma solução. Ainda prefiro um conjunto de boas práticas e outras coisas mais pontuais para resolução de problemas.

[]'s

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

com certeza Tarso, isso seria uma das vantagens, a tb outras vantagens além das desvantagens claro.

Notícias, artigos e o maior fórum brasileiro sobre Java