Migrar Hibernate para JPA

O que o pessoal vai falar é aquela coisa, se você usa o JPA você fica “independente do provider” pode mudar de Hibernate pra EclipseLink que teoricamente tudo vai funcionar.

Agora tem 2 detalhes:

1 - Dificilmente alguém troca de provider, não estou dizendo que não ocorre, simplesmente que não é muito comum.
2 - O Hibernate tem coisas interessantes que não são do JPA, escolher abrir mão delas pra ganhar a “independência” de provider pode não valer a pena.

Eu sempre utilizei JPA puro com alguma implementação.

A vantagem que se tem é que utilizando o JPA puro, você poderá migrar a implementação apenas alterando o jar e o arquivo persistence.xml.

Realmente o Criteria do JPA é horrível, para isso que o projeto EasyCriteria foi criado: EasyCriteria ? Utilizando a Criteria do JPA de um modo simples

E eu sempre utilizei HQL/JPQL ao invés de critéria mesmo com Hibernate puro. [=

Criteria do JPA é difícil?
Olha como é simples listar todos os elementos do banco de dados:

CriteriaBuilder cb = em.getCriteriaBuilder();
		CriteriaQuery<Medico> cq = cb.createQuery(Medico.class);
		Root<Medico> root = cq.from(Medico.class);
		cq.select(root);
		TypedQuery<Medico> tq = em.createQuery(cq);
		return tq.getResultList();

Ao invés de usar isto:

String query = "SELECT m FROM Medico m";
return em.createQuery(query).getResultList();

drsmachado:

Criteria do JPA é difícil?
Olha como é simples listar todos os elementos do banco de dados:

CriteriaBuilder cb = em.getCriteriaBuilder();
		CriteriaQuery<Medico> cq = cb.createQuery(Medico.class);
		Root<Medico> root = cq.from(Medico.class);
		cq.select(root);
		TypedQuery<Medico> tq = em.createQuery(cq);
		return tq.getResultList();

Ao invés de usar isto:

String query = "SELECT m FROM Medico m";
return em.createQuery(query).getResultList();

jakefrog:

drsmachado:

Criteria do JPA é difícil?
Olha como é simples listar todos os elementos do banco de dados:

CriteriaBuilder cb = em.getCriteriaBuilder();
		CriteriaQuery<Medico> cq = cb.createQuery(Medico.class);
		Root<Medico> root = cq.from(Medico.class);
		cq.select(root);
		TypedQuery<Medico> tq = em.createQuery(cq);
		return tq.getResultList();

Ao invés de usar isto:

String query = "SELECT m FROM Medico m";
return em.createQuery(query).getResultList();

cof cof cof modo propaganda on cof cof cof
com o EasyCriteria seria:EasyCriteria<Medico> easyCriteria = EasyCriteriaFactory.createQuery(entityManager, Medico.class); return easyCriteria.getResultList(); :twisted:

drsmachado:

Criteria do JPA é difícil?
Olha como é simples listar todos os elementos do banco de dados:

CriteriaBuilder cb = em.getCriteriaBuilder();
		CriteriaQuery<Medico> cq = cb.createQuery(Medico.class);
		Root<Medico> root = cq.from(Medico.class);
		cq.select(root);
		TypedQuery<Medico> tq = em.createQuery(cq);
		return tq.getResultList();

Ao invés de usar isto:

String query = "SELECT m FROM Medico m";
return em.createQuery(query).getResultList();

Não disse que é dificil, mas sim que é trabalhoso.

Fazer o mesmo com criteria do hibernate, é menos trabalhoso.

Mas valeu pelas considerações e opinião de todos.

Também acho besteira essa história de usar JPA sem ter reais motivos. Ainda bem que no .NET não existe essa tal especificação e projeto NHibernate pode evoluir livre de papelada.

javaflex:

Também acho besteira essa história de usar JPA sem ter reais motivos. Ainda bem que no .NET não existe essa tal especificação e projeto NHibernate pode evoluir livre de papelada.

jakefrog:

javaflex:

Também acho besteira essa história de usar JPA sem ter reais motivos. Ainda bem que no .NET não existe essa tal especificação e projeto NHibernate pode evoluir livre de papelada.

Não entendo qual o problema da especificação. O Hibernate tem um monte de função a mais que não existe na especificação.
E o .net não ter uma especificação próprio é o que eu vejo como maior problema. Você fica preso ao NHibernate e na hora de mudar, seria um trabalho 40x pior.

Foi mal, tinha entendido que o Hibernate do Java passou a ficar preso à especificação depois que a mesma foi criada. Pois acho que o Hibernate do Java deveria estar mais evoluído. No .NET, mesmo sendo uma versão magra, ele está mais evoluído no que diz respeito a querys em objetos e mapeamento, ao invés de deixar o mapeamento amarrado na entidade por annotations, podemos mapear por código em outra classe. E o QueryOver (baseado em Criteria por dentro) é muito melhor de manter.

Ficar preso ao Hibernate hoje não vejo problema se não existe um grande concorrente em uso. Não existem rumores do Hibernate deixar de ser muito usado à médio prazo. Daqui a mais de 20 anos isso pode ocorrer sim, mas muitas outras coisas também terão mudado e tudo ou alguns módulos serão feitos do zero de qualquer forma, até o negócio envolvido será renovado, como já aconteceu nas últimas décadas, e isso será até mais prazeroso do que deixar de usufruir de tudo de bom que tem hoje.

Mas o que vocês tanto temem de realidade para usar JPA e não ter a liberdade de usar diretamente o imbatível Hibernate? Eu trabalho com .NET e o Hibernate é mais respeitado do que o próprio ORM da Microsoft.

javaflex:

Foi mal, tinha entendido que o Hibernate do Java passou a ficar preso à especificação depois que a mesma foi criada. Pois acho que o Hibernate do Java deveria estar mais evoluído. No .NET, mesmo sendo uma versão magra, ele está mais evoluído no que diz respeito a querys em objetos e mapeamento, ao invés de deixar o mapeamento amarrado na entidade por annotations, podemos mapear por código em outra classe. E o QueryOver (baseado em Criteria por dentro) é muito melhor de manter.

Ficar preso ao Hibernate hoje não vejo problema se não existe um grande concorrente em uso. Não existem rumores do Hibernate deixar de ser muito usado à médio prazo. Daqui a mais de 20 anos isso pode ocorrer sim, mas muitas outras coisas também terão mudado e tudo ou alguns módulos serão feitos do zero de qualquer forma, até o negócio envolvido será renovado, como já aconteceu nas últimas décadas, e isso será até mais prazeroso do que deixar de usufruir de tudo de bom que tem hoje.

Mas o que vocês tanto temem de realidade para usar JPA e não ter a liberdade de usar diretamente o imbatível Hibernate? Eu trabalho com .NET e o Hibernate é mais respeitado do que o próprio ORM da Microsoft.

Se alguma melhor implementação de JPA aparecer, é muito mais simples de mudar. [=

jakefrog:

javaflex:

Foi mal, tinha entendido que o Hibernate do Java passou a ficar preso à especificação depois que a mesma foi criada. Pois acho que o Hibernate do Java deveria estar mais evoluído. No .NET, mesmo sendo uma versão magra, ele está mais evoluído no que diz respeito a querys em objetos e mapeamento, ao invés de deixar o mapeamento amarrado na entidade por annotations, podemos mapear por código em outra classe. E o QueryOver (baseado em Criteria por dentro) é muito melhor de manter.

Ficar preso ao Hibernate hoje não vejo problema se não existe um grande concorrente em uso. Não existem rumores do Hibernate deixar de ser muito usado à médio prazo. Daqui a mais de 20 anos isso pode ocorrer sim, mas muitas outras coisas também terão mudado e tudo ou alguns módulos serão feitos do zero de qualquer forma, até o negócio envolvido será renovado, como já aconteceu nas últimas décadas, e isso será até mais prazeroso do que deixar de usufruir de tudo de bom que tem hoje.

Mas o que vocês tanto temem de realidade para usar JPA e não ter a liberdade de usar diretamente o imbatível Hibernate? Eu trabalho com .NET e o Hibernate é mais respeitado do que o próprio ORM da Microsoft.

Um exemplo que eu vejo foi oq aconteceu aqui no guj.
Havia um bug no Eclipselink (post que um usuário abriu aqui falando), para testar e migrar para hibernate bastou mudar o xml e o jar.

Se alguma melhor implementação de JPA aparecer, é muito mais simples de mudar. [=