Caros companheiros, gostaria de debater/discutir vantagens e desvantagens na utilização do Hibernate puro vs. JPA com Hibernate…
A grande vantagem do uso do jpa é que vc não ficará preso somente ao hibernate.
Vamos dizer que no futuro vc queria mudar de framework de persistência por algum motivo.
Ou por que vc vai mudar de banco de dados e para esse banco de dados o top link seja melhor.
A mudança usando o jpa é praticamente zerada, mas se vc usar o hibernate puro certamente terá mais impacto.
Na nova versão do jpa 2.0 já trouxeram alguns benefícios como o critéria que não o deixa tão atrás em relação ao hibernate, e existem muitas promessas na próxima versão com mais recursos como esses.
Também sou favorável a sempre que for possível usar JPA ao invés de Hibernate diretamente.
[quote=otaviojava]
Na nova versão do jpa 2.0 já trouxeram alguns benefícios como o critéria que não o deixa tão atrás em relação ao hibernate, e existem muitas promessas na próxima versão com mais recursos como esses.[/quote]
Eu achei a API de criteria do JPA2 horrível de usar se comparada com a API do Hibernate.
Uma busca usando criteria no hibernate que é feita com aprox. 4 linhas de código, pelo JPA2 é feita com pelo menos umas 10 linhas.
[quote=otaviojava]A grande vantagem do uso do jpa é que vc não ficará preso somente ao hibernate.
Vamos dizer que no futuro vc queria mudar de framework de persistência por algum motivo.
[/quote]
Essa é uma das falácias conhecidas para se apontar as vantagens de se usar JPA.
Qual ser humano em estado são resolve mudar um framework de persistência de uma hora pra outra ? :lol:
[quote=otaviojava]
Na nova versão do jpa 2.0 já trouxeram alguns benefícios como o critéria que não o deixa tão atrás em relação ao hibernate, e existem muitas promessas na próxima versão com mais recursos como esses.[/quote]
Você citou um ponto interessante que eu já havia discutido uma vez com um professor de JPA, a questão de Criterias que no Hibernate em termos gerais ainda continua sendo melhor…
Já tive que fazer isso, pois o cliente para qual desenvolvia não queria mais pagar licença do Weblogic e passamos a utilizar o Glassfish. Por padrão o Weblogic 10 utilizava o BEA Kodo para JPA, e o mesmo não funciona em outro servidor de app. Tive que alterar para Hibernate. Como usava JPA, tive impactos mínimos de código.
Eu prefiro utilizar o hibernate puro justamente pq o JPA limita muito o hibernate, mais eu ainda não sei como esta a nova versão do JPA , pois ouvi falar que iria existir algo similar ao Criteria do hibernate, mais enquanto não tem prefiro utilizar os recursos do hibernate, como por exemplo o Criteria e o Example.
Mais é bom o programador analisar bem, pois uma vez com o hibernate puro para trocar vai dar um trabalho, não é algo impossível e nem muito complicado (ao meu ver), mais é trabalho, e c vc estiver usando um servidor de aplicação free vc ñ ira passar o problema que o ‘amhfilho’ passou…
Eu uso muito o hibernate puro em software do ramo financeiro (bancos, assessorias) e as alterações são imensas sem contar a dinâmica no negocio e o hibernate me permite fazer alterações super rapidas e nunca me deixou na mão e me deu uma produtividade imensa, eu não adiciono o JPA, pois tenhu uma aplicação que usa e o tempo de alteração e bem superior q as aplicações com o hibernate. só uso JPA quando ele tiver algo similar ao hibernate, não tem vantagem ao meu ver…
Segue ai para conhecimento, projeto free para agilizar o desenvolvimento da parte de consultas com uso do hibernate
http://www.guj.com.br/java/221618-filter-dinamico-para-hibernate
Já tive que fazer isso, pois o cliente para qual desenvolvia não queria mais pagar licença do Weblogic e passamos a utilizar o Glassfish. Por padrão o Weblogic 10 utilizava o BEA Kodo para JPA, e o mesmo não funciona em outro servidor de app. Tive que alterar para Hibernate. Como usava JPA, tive impactos mínimos de código.[/quote]
Legal.Pode contar mais sobre a experiência ? O tempo que levou,os problemas encontrados etc?
Tivemos alguns contratempos nesta mudança, realmente não foi simplesmente alterar o persistence.xml e botar pra rodar. Apesar de não utilizarmos nada muito específico do provider - no caso o BEA Kodo, uma extensão do OpenJPA - utilizávamos as anotações:
@DiscriminatorColumn
@DiscriminatorValue
Por algum motivo desconhecido simplesmente estas anotações não surtiam efeito algum na implementação antiga. Quando mudamos para o Hibernate, começamos a pegar uma série de bugs no código por que as anotações começaram a funcionar de fato. Tentamos utilizar o Oracle Toplink - padrão do Glassfish 2.1 - mas algumas consultas mais elaboradas retornavam erro. A implementação mais estável foi a do hibernate. Perdemos cerca de 40 horas para fazer esta transição, testando todas as operações de banco, mesmo porque não migramos somente a persistência, mas o servidor de aplicações também. Também tivemos que efetuar algumas configurações mais específicas para utilizar o log4j no servidor, pois por padrão o Glassfish 2.1 utiliza o log do próprio JavaSE.
[quote=amhfilho]Tivemos alguns contratempos nesta mudança, realmente não foi simplesmente alterar o persistence.xml e botar pra rodar. Apesar de não utilizarmos nada muito específico do provider - no caso o BEA Kodo, uma extensão do OpenJPA - utilizávamos as anotações:
@DiscriminatorColumn
@DiscriminatorValue
Por algum motivo desconhecido simplesmente estas anotações não surtiam efeito algum na implementação antiga. Quando mudamos para o Hibernate, começamos a pegar uma série de bugs no código por que as anotações começaram a funcionar de fato. Tentamos utilizar o Oracle Toplink - padrão do Glassfish 2.1 - mas algumas consultas mais elaboradas retornavam erro. A implementação mais estável foi a do hibernate. Perdemos cerca de 40 horas para fazer esta transição, testando todas as operações de banco, mesmo porque não migramos somente a persistência, mas o servidor de aplicações também. Também tivemos que efetuar algumas configurações mais específicas para utilizar o log4j no servidor, pois por padrão o Glassfish 2.1 utiliza o log do próprio JavaSE.
[/quote]
A aplicação possuia testes automatizados?
Realmente, ficar independente da camada de persistência não é tão frequente quanto ficar independente de banco de dados, que já gera polêmica.
Sem falar que muitas vezes a vantagem do framework está justamente nos seus diferenciais e não no que existe de padrão em todos.
Acho que é mais uma situação do tipo “depende, cada caso é um caso”. Onde trabalho hoje usamos JSF 1.2 + Hibernate e recentemente estamos no mesmo dilema se quando passar pro Java EE 6 se vamos implementar em JPA ou se vamos ficar no Hibernate, que é muito bom e atende bem.
Uma proposta que fizeram é no DAO genérico algumas coisas ficar em JPA e outras no Hibernate, mas não sei se é a melhor abordagem, tenho a impressão de ser a pior.
[quote=marcosalex]Realmente, ficar independente da camada de persistência não é tão frequente quanto ficar independente de banco de dados, que já gera polêmica.
Sem falar que muitas vezes a vantagem do framework está justamente nos seus diferenciais e não no que existe de padrão em todos.
Acho que é mais uma situação do tipo “depende, cada caso é um caso”. Onde trabalho hoje usamos JSF 1.2 + Hibernate e recentemente estamos no mesmo dilema se quando passar pro Java EE 6 se vamos implementar em JPA ou se vamos ficar no Hibernate, que é muito bom e atende bem.
Uma proposta que fizeram é no DAO genérico algumas coisas ficar em JPA e outras no Hibernate, mas não sei se é a melhor abordagem, tenho a impressão de ser a pior.[/quote]
Nossa e é elegante ter hibernate e jpa num mesmo projeto?
Você tem que avaliar quais são os benefícios ao passar pro Java EE + JPA. Com certeza não será uma migração tão tranquila, bastante código será alterado.
Sem pensar muito sobre isso já tenho a impressão de que isso não é uma boa idéia. Você vai ter que gerenciar o Entity Manager e o Session do Hibernate, e pelo que sei os dois não se conversam. Porque não fica no Hibernate puro?
Pois é, na minha opinião não, já que vai continuar dependente do Hibernate do mesmo jeito e vai ter de conviver com duas sintaxes.
Mesmo que na nossa situação em específico o uso do Hibernate fica restrito a um DAO genérico, a impressão que tenho é que não compensa, mas não encontramos consenso pra nenhum dos cenários.
[quote=amhfilho]
Sem pensar muito sobre isso já tenho a impressão de que isso não é uma boa idéia. Você vai ter que gerenciar o Entity Manager e o Session do Hibernate, e pelo que sei os dois não se conversam. [/quote]
Pior que conversam, através do Entity Manager eu consigo pegar a Session e fazer um cast pra Session do Hibernate. E pela Session do Hibernate eu também consigo fazer o inverso e ler a Entity Manager.
Por mim ficaria, prefiro a forma mais simples, mesmo que perca um pouco a independencia de tecnologia.
Mas não sou eu quem decide no final. 
E em termos de tunning/performance de queries? Alguém já teve alguma experiência com isso ou algo relevante a comentar?
Com o hibernate puro, consegui fazer alguns tunnings que melhorou em cerca de 60% a performance da aplicação, com JPA ainda não fiz testes.
Porcentagem de aumento de performance realmente plausível…
Abraço,
Aliás, pode citar trechos de código, como eram e como estão agora?
Melhoramentos foram proporcionados pelo cacheamento e no tunning das queries. Posso te mandar cfg.xml e queries novas, as antigas eu não tenho.