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 ? :shock:
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 :shock: eu particularmente acho isso meio loucura.
[]'s
[quote=WRYEL]você quer programar em java estilo código C ou assembly ? :shock:
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 :shock: eu particularmente acho isso meio loucura.
[]'s[/quote]
Te entendo, eu tinha pensando em não usar DAO porque a aplicação vai ser simples mas agora vou repensar o caso.
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:
public class Entidade {
private Session sessao;
public void salva() {
sessao.save(this);
}
}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.
[quote=wingb]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.[/quote]
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:
[code]public class Usuario {
private String nome;
private String senha;
private UsuarioRepo repo;
public Usuario(String nome, String senha, UsuarioRepo repo) {
this.nome = nome;
this.senha = senha;
this.repo = repo;
}
public boolean logar() {
}
public void deslogar() {
}
public void umMetodoQUsaRepo() {
repo.save();
}
}[/code]
Agora se lá na camada da GUI eu precisar chamar o repositório para salvar ou atualizar um usuário no banco?
Farei isso?
Usuario usuario = new Usuario("teste", "teste", repo);
repo.save(usuario);
Eu dei uma lida que alguns frameworks fazem DI mas não cheguei a me aprofundar. O que vocês sugerem?
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.
É uma opção. Discorra sobre ela.
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.
Ufa… pensei que eu era o único.