Todavia, vi em algum outro tutorial que não era necessário nada disso. Estou com dúvida em: Qual classe implemento os métodos de inserção, exclusão e alteração do banco ? Criei uma pasta chamada ‘Hibernate’ contendo os arquivos HibernateUtil.java, e os xml de configuração e engenharia reversa. É errado fazer isso?
Isso é extremamente relativo.
Eu prefiro trabalhar com annotations e hibernate.properties e acho o uso de hbm.xml um saco.
De qualquer forma, eu vejo que a classe HibernateUtil deve ser responsável (lembra das responsabilidades de uma classe?) pela criação da sessão (isso significa conectar-se ao banco e cria a sessão) e destruição da mesma, bem como pelos eventuais commit e rollback.
A abordagem que você viu me parece usar o design pattern DAO que é uma das várias formas utilizadas (e muito criticada, pois o ORM já abstrai a camada de persistência). Eu gosto do DAO, me dá mais liberdade. É nos DAOs que eu deixo meus métodos de persistência (CRUD, se preferir).
Normalmente eu faço:
package br.com.empresa.projeto.beans:
ClassePersistente.java: Classe que contém a PK e atributos comuns a todas as entidades;
Demais entidades.
package br.com.empresa.projeto.dao:
BaseDAO<E extends ClassePersistente, ID extends Serializable>: Interface que contém os métodos genéricos de CRUD.
Demais interfaces DAO (que conterão os métodos específicos)
package br.com.empresa.projeto.dao.impl:
AbstractBaseDAO<E extends ClassePersistente, ID extends Serializable>: Classe abstrata responsável pela execução dos métodos de CRUD.
Demais classes que extendem de AbstractBaseDAO e implementam as interfaces DAO respectivas do package dao.
package br.com.empresa.projeto.dao.util:
HibernateUtil: Classe que cria e destrói a instância de Session (Configuration, SessionFactory e ServiceRegistry também) e que realiza o comiit ou rollback quando necessários.
Mapear com Annotations nas entidades é gambiarra!!! Fere o que você mesmo mencionou bem em outro caso sobre a importância da responsabilidades de uma classe. XML realmente é um saco, mas Hibernate do Java ainda não há saída, que seria poder mapear programaticamente como no NHibernate do .NET.
Gambiarra? A JPA 2 incluiu o suporte à annotations e no JEE é o que é mais recomendado, logo, de onde tirou que é gambiarra?
Aliás, você desenvolve com JSF 2? EJB 3.1? JPA 2.0?
Daqui a pouco vai dizer que criteria também é gambiarra…
E, se formos analisar do ponto de vista de responsabilidade de uma classe, temos que considerar que toda iniciativa ORM está fora disto. Eu teria, obrigatoriamente, que ter uma classe que respondesse por esse processo, logo, o mais adequado seria o JDBC.
Gambiarra? A JPA 2 incluiu o suporte à annotations e no JEE é o que é mais recomendado, logo, de onde tirou que é gambiarra?
Aliás, você desenvolve com JSF 2? EJB 3.1? JPA 2.0?
Daqui a pouco vai dizer que criteria também é gambiarra…
E, se formos analisar do ponto de vista de responsabilidade de uma classe, temos que considerar que toda iniciativa ORM está fora disto. Eu teria, obrigatoriamente, que ter uma classe que respondesse por esse processo, logo, o mais adequado seria o JDBC.[/quote]
Entendo seu ponto de vista, está coberto por uma “garantia” da mãe da tecnologia. Mas não é porque uma igreja prega algo que aquilo tem que ser seguido cegamente ferindo outras recomendações a qual você mesmo defendeu, no caso, mapear via annotations gera mais responsabilidades para a classe, além de acoplamento ao ORM.
JPA sou contra, ainda não vi motivos reais de uso. Não tenho nada contra a Criteria, pelo contrário, só acho que o Hibernate para Java está atrasado não oferecendo algo mais fortemente orientado a objetos, sem exagero de strings pelo código. Só quis citar que no futuro poderia ter algo tipo o QueryOver do NHibernate que deixa o programador num alto nível para Criteria, mas isso deve rolar depois que Lambda Expression chegar na linguagem Java.
Mas você questiona meu ponto de vista, colocando um outro que depende da cobertura de tecnologia.
JPA é uma padronização, definida na especificação e que tem como objetivo permitir uma maior abrangência e entendimento do que está sendo feito.
O Criteria do JPA é ridículo, muito complexo, mas isso não tira os méritos de poder escolher entre qualquer provider mudando poucas configurações. Agora, além do NHibernate, como você faria para persistir? Teria que mudar toda a estrutura e apelar para ADO.NET, certo?
[quote=drsmachado]Mas você questiona meu ponto de vista, colocando um outro que depende da cobertura de tecnologia.
JPA é uma padronização, definida na especificação e que tem como objetivo permitir uma maior abrangência e entendimento do que está sendo feito.
O Criteria do JPA é ridículo, muito complexo, mas isso não tira os méritos de poder escolher entre qualquer provider mudando poucas configurações. Agora, além do NHibernate, como você faria para persistir? Teria que mudar toda a estrutura e apelar para ADO.NET, certo?[/quote]
Se Criteria do JPA é complexo, por que não usar Hibernate puro e ser mais feliz? O que essa padronização e facilidade para troca de persistência significa para a realidade do projeto? Para mim pelo menos nunca fez sentido na prática, já vi relatos que fez sentido, mas por terem usado outra implementação de ORM menos consolidada no mercado.
Além do NHibernate? Qual problema real eu teria para se preocupar com isso? Isso vale para qualquer coisa que usamos, como framework web por exemplo.
Mas enfim, respeito se achou como a melhor escolha para o seu projeto, segue a vida que terá o mesmo sucesso, tudo tem prós e contras mesmo, mas eu defendo mais a realidade, limpeza das classes, etc.
Você só trabalha em um projeto a vida toda? Fantástico…
Depois dessa, melhor deixar para lá.[/quote]
Onde eu falei isso? Estou mais de uma década na área passando por muitos projetos e outras tecnologias, mesmo assim isso não vem ao caso. Só defendi o que considero do que foi falado, para um projeto num horizonte atual. Procure não levar a discussão para o lado pessoal, eu só foco discussões sobre assunto.