JPA sem DAO

Encontro um ponto positivo na produção de uma aplicações com DAO.

Podemos ter pessoas especializadas em buscar informações
armazendas (xml, banco de dados, txt) no contexto da aplicação,
que se preocupam apenas com a persistencia de informação, enquanto
a outra parte da equipe desenvolve visões e objetos de negocio.

Visando a parte de produção acho que é um ponto positivo, o uso do DAO.

Em relação ao uso de JPA e suas anotações, é muito bom,
é prático desenvolver, não sou especialista no assunto,
mas na maioria das vezes que usei JPA, usei também um DAO responsavel
por Entidade.

--------
Simple words!
-----------

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

higorcoelho wrote: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.

O EntityManager é um implementação do padrão DomainStore. Um DomainStore utiliza um DAO dentro dele. Logo, o DomainStore é algo "maior" que um DAO. Logo um DAO nunca deve conter um DomainStore. Então, se for usar o EntityManager utilizar DAO é um sinal da sua incompreensão de arquitetura de sistemas e padrões de projeto.

Então, se quiser utilizar EntityManager não utilize DAO. Se quiser usar DAO, não utilize EntityManager.

Se o EntityManager deve ser injetado nas classes... depende. Para pesquisas não. Devem passar pelo Repositorio apropriado. Para atualizações pode até colocar, mas pode igualmente utilizar o Repositorio para isso caso queira.
Aqui não é muito critico já que em tese vc está invocando o EntityManager de dentro de um serviço ou façade , logo, caso necessário pode ser alterado sem afetar o resto da aplicação.

Pensei em levantar o assunto na lista depois de uma conversa com um ex-colega de trabalho (que hoje so quer saber de RIA e pensei que ele participaria desta discussão).

A discussão esta muito boa e no inicio não quis expor minhas opiniões para não direcionar a discussão deixando ela fluir naturalmente.

Na hora eu defendi o DAO mas depois fiquei me questionando para saber se não estava sendo muito radical. Sei que a JPA tem muita coisa pra evoluir, falta busca por exemplos, criterias e tudo mais.

Ele defendeu o uso da JPA sem o DAO usando a seguinte argumentação: "me parece que JPA é mais pratico usar quando posso garantir que meu acesso será apenas a uma base relacional, enquanto o DAO me permite mais flexibilidade, mas se agora nós temos a JPA pra abstrair o acesso a bancos de dados relacionais, ainda faz sentido implementar os famosos DAOs ou o negócio é meter EntityManager direto em código? Sem falar que com a JPA estou seguindo a especificação, diminuo a burocracia e alavanco a produtividade".

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

higorcoelho wrote:
Ele defendeu o uso da JPA sem o DAO usando a seguinte argumentação: "[...]Sem falar que com a JPA estou seguindo a especificação, diminuo a burocracia e alavanco a produtividade".

Isso não é verdade pela razão já apontada aqui. o JPA não é uma especificação completa.
O JPA trabalha como um DomainStore mas faltam-lhe capacidades de pesquisa desacoplada. O Hibernate já tem isso, então, em tese para ser menos burucrático e mais produtivo deveria usar Hibernate.

Todo o ponto destas conversas é só um : A aplicação NUNCA deve conhecer o sistema de persistencia do seu estado. Quando isso não é isolado o suficiente e ela conhece, o dano está feito. Então o que ha a decidir é o nivel de isolamento da persistencia ( alterações+pesquisa) e ir conforme a decisão.

Desacoplamento Total = Entidades não Anotadas + Repositorio + QueryObject + interface DAO agnostica + Implementação do DAO para a API escolhida.

Acoplamento Total = Entidades anotadas + DAO especifico de negocio e da API escolhida.

Fazer bem não demora mais, apenas tem mais niveis e é preciso mais cuidado com as interfaces dos métodos e a implmentação. Fazer rápido fica pronto antes mas sofre na hora de manter e evoluir.

sergiotaborda wrote:

higorcoelho wrote: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.

O EntityManager é um implementação do padrão DomainStore. Um DomainStore utiliza um DAO dentro dele. Logo, o DomainStore é algo "maior" que um DAO. Logo um DAO nunca deve conter um DomainStore. Então, se for usar o EntityManager utilizar DAO é um sinal da sua incompreensão de arquitetura de sistemas e padrões de projeto.

Então, se quiser utilizar EntityManager não utilize DAO. Se quiser usar DAO, não utilize EntityManager.

Se o EntityManager deve ser injetado nas classes... depende. Para pesquisas não. Devem passar pelo Repositorio apropriado. Para atualizações pode até colocar, mas pode igualmente utilizar o Repositorio para isso caso queira.
Aqui não é muito critico já que em tese vc está invocando o EntityManager de dentro de um serviço ou façade , logo, caso necessário pode ser alterado sem afetar o resto da aplicação.

Sergio,

Não criando classes DAO, onde ficaria querys especificas? No próprio Facade ou Services?

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

sergiotaborda wrote:

higorcoelho wrote:
Ele defendeu o uso da JPA sem o DAO usando a seguinte argumentação: "[...]Sem falar que com a JPA estou seguindo a especificação, diminuo a burocracia e alavanco a produtividade".

Isso não é verdade pela razão já apontada aqui. o JPA não é uma especificação completa.
O JPA trabalha como um DomainStore mas faltam-lhe capacidades de pesquisa desacoplada. O Hibernate já tem isso, então, em tese para ser menos burucrático e mais produtivo deveria usar Hibernate.

Todo o ponto destas conversas é só um : A aplicação NUNCA deve conhecer o sistema de persistencia do seu estado. Quando isso não é isolado o suficiente e ela conhece, o dano está feito. Então o que ha a decidir é o nivel de isolamento da persistencia ( alterações+pesquisa) e ir conforme a decisão.

Desacoplamento Total = Entidades não Anotadas + Repositorio + QueryObject + interface DAO agnostica + Implementação do DAO para a API escolhida.

Acoplamento Total = Entidades anotadas + DAO especifico de negocio e da API escolhida.

Fazer bem não demora mais, apenas tem mais niveis e é preciso mais cuidado com as interfaces dos métodos e a implmentação. Fazer rápido fica pronto antes mas sofre na hora de manter e evoluir.

Não quero ser chato, mas vc está sendo xiita. Esquece essa meu. Isso contamina os mais novos, porém, me diz, como vc torna isso prático? Como isso não vai tomar mais o tempo de desenvolvimento? No que ganho a longo prazo?
O Hibernate não implementa a JPA atoa. Vc acha que ele sem JPA vai ser o futuro?
Nada começa completo mas, porém, evolui. Aliás, em Java, tudo é mais lento mesmo. Pior ainda qdo querem fazer a coisa mais "desacoplada" que existe.
Eu uso o Spring, JPA, Hibernate com DAO genérico e pronto. Fica fácil de manutenir e mais simples de entender.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

phstc wrote:

sergiotaborda wrote:(...)

Então, se quiser utilizar EntityManager não utilize DAO. Se quiser usar DAO, não utilize EntityManager.

Se o EntityManager deve ser injetado nas classes... depende. Para pesquisas não. Devem passar pelo Repositorio apropriado. Para atualizações pode até colocar, mas pode igualmente utilizar o Repositorio para isso caso queira.
Aqui não é muito critico já que em tese vc está invocando o EntityManager de dentro de um serviço ou façade , logo, caso necessário pode ser alterado sem afetar o resto da aplicação.

Sergio,

Não criando classes DAO, onde ficaria querys especificas? No próprio Facade ou Services?

Ficam nos Repositorios!!!

No service vc precisa, por exemplo, de todos os clientes que já fizeram compras na loja X. Vc escreve um método no repositorio de Cliente assim

e no seu serviço

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

djemacao wrote:

sergiotaborda wrote:
Todo o ponto destas conversas é só um : A aplicação NUNCA deve conhecer o sistema de persistencia do seu estado. Quando isso não é isolado o suficiente e ela conhece, o dano está feito. Então o que ha a decidir é o nivel de isolamento da persistencia ( alterações+pesquisa) e ir conforme a decisão.

Desacoplamento Total = Entidades não Anotadas + Repositorio + QueryObject + interface DAO agnostica + Implementação do DAO para a API escolhida.

Acoplamento Total = Entidades anotadas + DAO especifico de negocio e da API escolhida.

Fazer bem não demora mais, apenas tem mais niveis e é preciso mais cuidado com as interfaces dos métodos e a implmentação. Fazer rápido fica pronto antes mas sofre na hora de manter e evoluir.

Não quero ser chato, mas vc está sendo xiita. Esquece essa meu. Isso contamina os mais novos
me diz, como vc torna isso prático? Como isso não vai tomar mais o tempo de desenvolvimento? No que ganho a longo prazo?

Sepração de Responsabilidade, Inversão de Controle e encapsulamento. Isso se traduz em :
TDD fácil, DDD simples, DAO reaproveitável entre projetos. Vc pode começar e completar o sistema sem uma única chamada a banco , vc pode dividir o trabalho mais facilmente, em uma palavra vc pode usufruir de OO em sua plena capacidade. Se seguir OO é ser xiita, que seja.

O Hibernate não implementa a JPA atoa. Vc acha que ele sem JPA vai ser o futuro?

Não.

Nada começa completo mas, porém, evolui. Aliás, em Java, tudo é mais lento mesmo. Pior ainda qdo querem fazer a coisa mais "desacoplada" que existe.
Eu uso o Spring, JPA, Hibernate com DAO genérico e pronto. Fica fácil de manutenir e mais simples de entender.

Se funciona para vc otimo. Não funciona para mim.

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