Hibernate ou JPA ?

Em nossos projetos utilizamos o Hibernate, pois até a data de inicio do desenvolvimento não existia o JPA.

Estou para iniciar um novo projeto, porém gostaria de algumas opiniões sobre o JPA comparado ao Hibernate, ou se deveria partir direto para JPA ?

Obrigado.

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1850 Offline

A diferenca entre JPA e Hibernate é a seguinte..

usando hibernate:

usando JPA:

o problema no JPA é que as vezes vc vai precisar de métodos específicos da implementacao... entao vc faz

A analogia nao ficou muito perfeita nao.. mas é por aí

This message was edited 1 time. Last update was at 16/07/2010 02:07:59

rogelgarcia wrote:A diferenca entre JPA e Hibernate é a seguinte..

usando hibernate:
ArrayList al = new ArrayList();

usando JPA:
Collection c = new ArrayList();

o problema no JPA é que as vezes vc vai precisar de métodos específicos da implementacao... entao vc faz
Collection c = new ArrayList(); ArrayList al = (ArrayList)c; al.get(1230);

A analogia nao ficou muito perfeita nao.. mas é por aí

[OFF]
Rogel,
Sinceramente não entendi essa analogia

[/OFF]

Quanto a pergunta, respondo com outra: Por que não usar os dois?

O que acontece é o seguinte...JPA e Hibernate são coisas diferentes.
JPA é uma especificação. Hibernate, uma implementação.
Se tu optar por utilizar a especificação JPA, tu vai ter que utilizar uma implementação...seja o Toplink, Hibernate, eclipseLink...

Fernando

Lucas Emanuel wrote:[OFF]
Rogel,
Sinceramente não entendi essa analogia
[/OFF]

A analogia do Rogel é que a interface (Collection) é a especificação (JPA) e a classe (ArrayList) é a implementação (Hibernate).

O que acontece é o seguinte...JPA e Hibernate são coisas diferentes.
JPA é uma especificação. Hibernate, uma implementação.
Se tu optar por utilizar a especificação JPA, tu vai ter que utilizar uma implementação...seja o Toplink, Hibernate, eclipseLink...

tbm acho isso!

tem como usar uma Especificação sem implementação?? acho que não!

Vc precisa de uma implementação.
A implementação de referência do JPA 2 é o EclipseLink.
http://www.theserverside.com/news/thread.tss?thread_id=48757

This message was edited 1 time. Last update was at 16/07/2010 11:43:38

Pelo que eu havia lido a algum tempo atrás a própria especificação JPA foi feito com base no Hibernate, porém na minha "ignorância", imaginava que poderia utilizar diretamente o JPA como um framework ORM (integrado ao JRE/JDK) em contra partida ao Hibernate, Toplink, Eclipselink e talvez outros...

Sendo assim não vejo motivos para mudar do Hibernate para outro framework ORM.

Alguma outro opinião ?

Obrigado a todos.

Vamos colocar ordem nas coisas.

JPA é apenas uma especificação, assim como o JDBC é apenas uma especificação. JPA por sí próprio não é nada, pois você precisa de uma implementação que é chamado de provider, que pode ser tanto o Hibernate, como o Eclipselink/Toplink, OpenJPA, etc; assim como pro JDBC você precisa de um driver do banco de dados.

Tanto o Hibernate como o Eclipselink podem ser usados separadamente em modo standalone como também podem funcionar como provider do JPA. A grande vantagem de usar qualquer um deles sobre o JPA é que se você quiser trocar de provider pode fazer sem alterar nada no seu código. Na verdade a única alteração é no persistence.xml alterar o nome do provider. Assim como no JDBC se você quiser trocar de banco de dados basta trocar o driver.

O JPA foi impulsionado pelo Emmanuel Bernard e pelo Gaving King, ambos do time do Hibernate e JBoss, porém a implementação de referência é o Eclipselink, que é do pessoal da Eclipse Fondation. Implementação de referencia significa apenas que o Eclipselink foi a cobaia da especificação, não que ele seja melhor nem mesmo que seja o padrão.

Quando o JEE6 foi lançando o Glassfish trouxe como provider padrão o Eclipselink como implementação padrão de JPA. Já o JBoss trouxe o Hibernate, e o roadmap do Geronimo pretende trazer o OpenJPA como padrão. Mas nada impede que a aplicação possa usar seu próprio provider, como é meu caso que normalmente uso Hibernate 3.5. como provider de JPA.

excelente explicacao garcia, melhor impossivel, parabens, enfim vc terá que sempre usar um provider com JPA, e normalmente usam o Hibernate. Agora usar JPA em um novo projeto é bem melhor evita varios problemas que o hibernate tem, e que nao sao poucos quando app vai pra producao. estou ate tratando sobre isso no meu blog www.camilolopes.com.br

enfim, novo projeto se puder ja der o start com JPA 2.0 e o provider a escolha.

flw!

Obrigado pessoal.
Agradeço a todos que comentaram aqui sua experiências e opiniões, pois sei que elas são muito valiosas.
Eu de fato tenho alguns problemas com o Hibernate, mas para não ter causado algum desconforto aos fãs do Hibernate, preferi não mencioná-las e também por respeito ao prato que como a cada dia, ou seja, vivo do Hibernate.

Novamente muito obrigado.

Isso é um fórum, e independente de paixões, é legal mencionar os problemas até mesmo para quem sabe reportar bugs para o developer team do Hibernate.

Quais os problemas vocês enfrentaram?

eh concordo com garcia, nada de paixao, eu nao mencionei os problemas para nao desfocar o topico, mas aqui alguns links, aonde abordo os possiveis problemas que temos com hibernate:
http://blog.camilolopes.com.br/open-session-view-%e2%80%93-hibernate-solucao/

usando JPA nao temos esse tipo de problema.

LPJava, JPA tem sim o mesmo problema.

Esse assunto do lazy-initialization é bem controverso porque muita gente acha X, outros Y, e outros Z. Há inúmeras discuções por aí sobre isso.

Para fins de exemplo, imagine o cenário que você tem um servlet que chama ométodo findUser do EJB UserRemote. Esse UserRemote tem um EntityManager lá dentro. Quando você carrega o objeto do banco e há alguma propriedade lazy-loaded que ainda não foi carregada antes de sair do EJB terá o lazy-initialization-exception. Isso porque quando acabou a execução dentro do EJB todas as referencias são finalizadas, e o EntityManager é finalizado.

Quando você, dentro do JSP, tentar ler uma propridade terá o mesmo problema que no Hibernate puro.

Fazendo uma pequena busca na internet há uma série de discuções sobre isso: http://www.google.com.br/search?q=jpa+lazy+initialization+exception. Há aqui mesmo no GUJ uma série de discuções sobre o certo e errado dessa exception. Não vou entrar muito no mérito disso, já que o intuito é apenas exemplificar que o JPA também tem esse erro.

Diferentemente do Hibernate, no JPA o valor padrão do fetch é EAGER, então quando você tem algum one-to-* ou many-to-* o JPA faz load non-lazy. Talvez por isso vocês não tenham recebido esse erro.

Eu sou um grande fã do JPA porque ele finalmente coloca um padrão para as ferramentas ORM. Eu tenho um projeto de cobrança eletrônica que utilizada Hibernate. Havia um cliente que usava uma plataforma completa Oracle, então ele tinha vontade de usar o Toplink para ficar integrado ao OC4J. Fiz a alteração em poucos minutos e estava lá rodando em Toplink.

garcia-jj wrote:LPJava, JPA tem sim o mesmo problema.

Esse assunto do lazy-initialization é bem controverso porque muita gente acha X, outros Y, e outros Z. Há inúmeras discuções por aí sobre isso.

Para fins de exemplo, imagine o cenário que você tem um servlet que chama ométodo findUser do EJB UserRemote. Esse UserRemote tem um EntityManager lá dentro. Quando você carrega o objeto do banco e há alguma propriedade lazy-loaded que ainda não foi carregada antes de sair do EJB terá o lazy-initialization-exception. Isso porque quando acabou a execução dentro do EJB todas as referencias são finalizadas, e o EntityManager é finalizado.

Quando você, dentro do JSP, tentar ler uma propridade terá o mesmo problema que no Hibernate puro.

Fazendo uma pequena busca na internet há uma série de discuções sobre isso: http://www.google.com.br/search?q=jpa+lazy+initialization+exception. Há aqui mesmo no GUJ uma série de discuções sobre o certo e errado dessa exception. Não vou entrar muito no mérito disso, já que o intuito é apenas exemplificar que o JPA também tem esse erro.

Diferentemente do Hibernate, no JPA o valor padrão do fetch é EAGER, então quando você tem algum one-to-* ou many-to-* o JPA faz load non-lazy. Talvez por isso vocês não tenham recebido esse erro.

Eu sou um grande fã do JPA porque ele finalmente coloca um padrão para as ferramentas ORM. Eu tenho um projeto de cobrança eletrônica que utilizada Hibernate. Havia um cliente que usava uma plataforma completa Oracle, então ele tinha vontade de usar o Toplink para ficar integrado ao OC4J. Fiz a alteração em poucos minutos e estava lá rodando em Toplink.

hmm, legal garcia, sua abordagem, eu de fato nao sabia do mesmo problema com JPA, ate pq nao passei pelo mesmo ainda. eh o velho ditado vivendo e aprendendo. mas, no hibernate se configurar para EAGER resolve o problema, mas nem sempre queremos EAGER .

Eu tb gosto da JPA, e o que vc citou como exemplo, eh show, salva o dia de qualquer desenvolvedor de software e ainda temos a satisfacao do cliente.

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