[org.hibernate.annotations vs javax.persistence] Qual das anotações utilizar e quando?

Assuntos Gerais
#1

Prezados,
Estava revendo alguns conceitos de Hibernate pelos tutoriais da DevMedia.

O instrutor utilizou Hibernate Core com anotações…Porém NÃO utilizou “EntityManagerFactory”.
Utilizou SessionFactory, ou seja, quer dizer que o hibernate dele estava trabalhando independêntemente da especificação JPA, Certo?

Caso positivo,
Por que ele utilizava as anotações da javax.persistence (JPA) para anotar id, colunas, relacionamentos etc…? E FUNCIONAVA!

Já que não se utiliza do EntityManager, não deveria se utilizar das anotações do org.hibernate.annotations do próprio framework?

Espero que tenham entendido minha dúvida, que é mais curiosidade mesmo.
Caso eu tenha entendido algum errado, por favor não deixem de me corrigir.

E por favor não postem “achismos” xD

Att,
Diogo Barbosa.

#2

para as anotações que tem no jpa o correto é você você usar as próprias, usando as coisas do hibernate apenas onde é específico. Um caso a parte onde você tem o objeto Query do org.hibernate e o do javax.persistence, nesse caso você tem no javax.persistence mas o tipo retornado pela Session do hibernate é o objeto Query do pacote org.hibernate, é essa que você tem que usar…

a é, e funciona por que a api do hibernate entende estas anotações na hora de montar o SessionFactory… que é mais ou menos um paralelo com o EntityManagerFactory.

#3

Então caso se use o “SessionFactory” , o correto é utilizar as anotações do org.hibernate.annotations ao invés de javax.persistence?
Mesmo ele reconhecendo as anotações de javax.persistence já que a maioria age igual as do hibernate…

#4

Então caso se use o “SessionFactory” , o correto é utilizar as anotações do org.hibernate.annotations ao invés de javax.persistence?
Mesmo ele reconhecendo as anotações de javax.persistence já que a maioria age igual as do hibernate…[/quote]

não… ao contrário (acho que me espressei mal), normalmente se usa as anotações do javax.persistence… eu não lembro aonde mas lembro de ter lido sobre usar estas (as do javax.persistence), não lembro de ter alguma justificativa, nunca usei a do org.hibernate também…

apenas uso a do hibernate no caso do objeto Query por exemplo… inclusive a interface org.hibernate.Query tem mais recursos, por exemplo o metodo setParameters que ja pode receber em arrays…

http://docs.jboss.org/hibernate/orm/3.2/api/org/hibernate/Query.html#setParameters(java.lang.Object[], org.hibernate.type.Type[])

http://docs.oracle.com/javaee/6/api/javax/persistence/Query.html

na api da especificação (entity manager) não tem esse recurso, não tem resultTransformers… tem umas coisas a menos, mas claro que usar esse tipo de coisa dificulta a migração para outra implementação de jpa (quando isso for importante para você).

#5

Então pode se dizer basicamente que querendo ou não, utilizando “SessionFactory / Annotations”, você acaba seguindo as regras do JPA?
Já que as anotações parecem ter sido feitas exatamente para se seguir a especificação independentemente da Fábrica utilizada…

Qual o sentido de usar SessionFactory com as anotações do javax.persistence, se não utilizar a própria EntityManager que foi feita pra isso?
O único modo de se estar afastado da especificação é usando SessionFactory com “hbm.xml”?

(Obs; Não é que eu ame trabalhar fora da especificação, só quero entender como as coisas funcionam >.<)

#6

[quote=InsaneChess]Então pode se dizer basicamente que querendo ou não, utilizando “SessionFactory / Annotations”, você acaba seguindo as regras do JPA?
Já que as anotações parecem ter sido feitas exatamente para se seguir a especificação independentemente da Fábrica utilizada…

Qual o sentido de usar SessionFactory com as anotações do javax.persistence, se não utilizar a própria EntityManager que foi feita pra isso?
O único modo de se estar afastado da especificação é usando SessionFactory com “hbm.xml”?

(Obs; Não é que eu ame trabalhar fora da especificação, só quero entender como as coisas funcionam >.<)[/quote]

olha… eu entendo que essa api tenha sido feita de forma a pegar o forte da especificação, aproveitado o que é bom e melhorado tapando alguns buracos. Tiveram os dois exemplos que eu citei, um outro exemplo seria quando você vai ter queries dinâmicas, aquelas telas por exemplo que tenham além de filtros com os campos quando você digitar, que tenham checkboxes para você “agrupar” por determinados campos (relatórios dinâmicos). Para fazer isso com sql (ou hql) da um certo trabalhinho, controlar o que você vai colocar no select, no group by, ver se determinados campos foram selecionados ou agrupados para caso sim, adicionar a tabela de onde está esse campo no “from” da query… na melhor das hipóteses o código para fazer isso fica extenso, trabalhoso, com alguns detalhes suscetíveis a bugs por que você esqueceu de algum detalhe… enfim… ai o pessoal do hibernate fez a api criteria, com criteria o código para fazer isso fica muito… muito melhor, é um cenário onde a especificação não estava atendendo muito bem (ao menos não com o que eu conheço dela), mas essa api atende bem…

agora que ja leu isso tudo que eu escrevi… enfim, SessionFactory segue as regras da especificação e acrescenta recursos.

quanto a segunda pergunta, o sentido de se usar Session ou SessionFactory com as anotações do javax.persistence é por que funciona, é bem produtivo, você tem o que a especificação diz e ainda tem mais coisas…

quanto a ficar distante da especificação, você pode configurar suas entidades com o hibernate no seu hbm.xml e com JPA pode mapear da mesma forma em xml, normalmente é usado um arquivo chamado orm.xml para deixar essa configuração, veja.

quanto a ficar distante da especificação acho que outros frameworks orm ficam mais distantes que o hibernate, como o ibatis ou o MentaBeans. não sei até por que nunca vi nenhum dos dois de perto, só li um pouquinho a respeito mesmo… mas não vejo uma vantagem sequer em ficar longe da especificação… você pode até ver vantagens em recursos meio distantes da especificação, mas essa distancia da especificação por si só não é uma vantagem.

a é, mais uma vez para ficar claro, tudo o que eu disse ai, ou quase tudo é a minha opinião, a forma como eu vejo isso tudo.

#7