Alternativas para o DAO

Olá pessoal,
Digamos que eu queira fazer um sistema de login com hibernate e não use DAO, com o acesso ao banco e as regras de negócio todas no Entity. Isso acaba perdendo um pouco do sentido já que a Entity é geralmente um POJO não? Qual seria uma boa solução para isso e outros casos evitando o uso de DAO e POJO?
Não sei se fui claro o suficiente, aguardo respostas.
Abraços.

você quer programar em java estilo código C ou assembly ?

cara ... isso vai virar uma bagunça hehe, o que eu vejo muito por ai, é a camada de negocio interagindo direto com o entity manager, até porquê, tem muito arquiteto e defensor de design pattern que diz que quando se usa jpa/hibernate, não há necessidade da camada de DAO

eu particularmente acho isso meio loucura.

[]'s

WRYEL wrote:você quer programar em java estilo código C ou assembly ?

cara ... isso vai virar uma bagunça hehe, o que eu vejo muito por ai, é a camada de negocio interagindo direto com o entity manager, até porquê, tem muito arquiteto e defensor de design pattern que diz que quando se usa jpa/hibernate, não há necessidade da camada de DAO eu particularmente acho isso meio loucura.

[]'s

Te entendo, eu tinha pensando em não usar DAO porque a aplicação vai ser simples mas agora vou repensar o caso.

JavaBaby Membro desde: 03/05/2011 23:21:06 Mensagens: 88 Offline

Cara, já ouviu falar do padrão Active Record? É o padrão adotado pelo Rails na parte da persistência. Dá uma olhada nele, e é bem parecido com o que você tinha pensado: a própria entity reponsável pelo seu armazenamento. A grosso modo, utilizando hibernate seria mais ou menos assim:

Isso seria um exemplo bem simplório do que seria o padrão Active Record. O lance seria a forma da entidade obter uma referência a uma sessão do Hibernate... Mas dá uma pesquisada aí nesse padrão pra ter uma nova perspectiva...

Vou dar uma estudada hoje e aplicar a solução que me parecer mais adequada. Amanhã posto ela e vocês dão as suas opiniões.
Obrigado pela ajuda.

wingb wrote:Vou dar uma estudada hoje e aplicar a solução que me parecer mais adequada. Amanhã posto ela e vocês dão as suas opiniões.
Obrigado pela ajuda.

Estuda bem os conceitos, o que é DAO, o que é entidade e o que é regra de negócio. Não misture regras de negócio com DAOs! São coisas distintas

Então pessoal, ainda não cheguei em uma conclusão mas tenho algumas ideias: deixarei as regras de negócio nas entities. Na questão da persistência, a ideia que tive foi utilizar uma combinação de HibernateUtil (ou um DAO genérico) junto com o padrão Repository quando fosse necessário manipular as consultas. Eu só fiquei com uma dúvida, vi um HibernateUtil tendo métodos de consulta ao banco, isso é correto?

Pessoal, tive a ideia de não deixar a minha entidade anêmica então deixei as regras de negócio nele. No entanto fiquei na dúvida quanto a persistência e a injeção de dependência e pensei nessa solução:

Agora se lá na camada da GUI eu precisar chamar o repositório para salvar ou atualizar um usuário no banco?
Farei isso?

Eu dei uma lida que alguns frameworks fazem DI mas não cheguei a me aprofundar. O que vocês sugerem?

HelloWorld Membro desde: 04/02/2012 13:21:13 Mensagens: 11 Offline

Qual o motivo, de se fazer dessa forma, já que o padrão Dao, é tão simples?

josernn17 wrote:Qual o motivo, de se fazer dessa forma, já que o padrão Dao, é tão simples?

Oi josernn17, o interessante disso é poder envolver buscas ou manipular dados nas entidades. A solução que eu encontrei para chegar nisso foi usando o padrão Repository. As entidades podem depender dele já que o mesmo pertence a camada de negócio.

Sobre o DAO, como foi comentado nesse tópico há uma discussão se devemos ou não utilizá-lo com frameworks ORM. Pessoalmente eu não gosto de DAO, então sempre procurei fugir dele em projetos na qual eu tivesse liberdade para isso, no entanto, é perfeitamente possível utilizar um DAO genérico e o Repository faria as chamadas para ele.

Uma opção mais interessante na minha opinião. Capa o Hibernate e mantem o seu DAO.

saoj wrote:Uma opção mais interessante na minha opinião. Capa o Hibernate e mantem o seu DAO.

É uma opção. Discorra sobre ela.

This message was edited 4 times. Last update was at 05/02/2012 19:22:48

Tive que olhar no dicionário o que é discorrer: http://www.dicionarioinformal.com.br/discorrer/

Esse tópico fala tudo sobre isso: http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

Simplificando: se vc sabe SQL é preferível utilizar um sql-builder / jdbc-helper com DAO e deixar de fora o hibernate que é uma complexidade maior (hibernate e todas as suas sacanagens, mágicas, suposições, HQL, Criteria, annotations, etc.) para simplificar uma complexidade menor (jdbc + sql) com ganhos bastante duvidosos.

Na minha humilde opinião abstração só cabe quando há simplificações claras. Hibernate resolve um problema (jdbc + sql) criando outro maior (veja a quantidade de dúvidas no GUJ sobre o Hibernate), logo isso não pode ser chamado de abstração.

Opções: MentaBean (http://mentabean.soliveirajr.com), iBatis, jOOQ, etc.

Eu acredito que essas opcões acima resolvem o problema jdbc de uma forma muito mais simples e menos intrusiva. Agora tem que saber SQL, que é a linguagem nativa dos banco-de-dados. Aprender HQL / Criteria sem saber SQL fica esquisito e com certeza vai te pegar lá na frente.

Olá saoj, vou estudar o seu framework e compará-lo com Hibernate nos próximos dias e ai decido o que usarei. Se eu tiver alguma dúvida ou colocação posto no tópico. Obrigado pela ajuda.

saoj wrote:Esse tópico fala tudo sobre isso: http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

Ufa... pensei que eu era o único.

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