JPA 2.0 em final review! Criteria no Java EE!

Aí eu vou discordar completamente. JPA tem diversas falhas e a falta de uma API de criteria é apenas a mais gritante delas, acessar o objeto do Hibernate é uma coisa completamente aceitável e normal quando você não quer fazer gambiarras bizonhas.

[quote=Mauricio Linhares]
Aí eu vou discordar completamente. JPA tem diversas falhas e a falta de uma API de criteria é apenas a mais gritante delas, acessar o objeto do Hibernate é uma coisa completamente aceitável e normal quando você não quer fazer gambiarras bizonhas.[/quote]

Bem, confesso que nunca consegui fugir das anotacoes “hibernate specific” (e hints) aqui na Caelum, mas, Fabio Kung e Guilherme Silveira me corrijam se estou enganado, nunca precisamos usar a Session que esta por tras do EntityManager. Creio que isso ocorre porque nos projetos que percebemos que iriamos ter de fazer essa lambança, optamos pelo Hibernate diretamente.

Com a versao 2.0 isso deve diminuir drasticamente… ta entrando second level cache, zilhares de opcoes novas de mapeamento de colecoes e de features que so o hibernate tinha. É torcer. Mas ai quando sair o hibernate4, estaremos defasados novamente.

Ora, usar JPA nunca significou abandonar o Hibernate, afinal de contas se o framework implementa a especificação JPA 1.0, por que não implementaria a próxima? A não ser que você esteja falando de Session, SessionFactory e correlatos.[/quote]

Mesmo que nao abandonasse o hibernate ele sempre tem funcionalidades a mais que a JPA. E se for para usar a JPA com o hibernate então prefiro usar o hibernate sózinho.

Nao lembro quem falou que talves eu usasse o hibernate antes do 3, mas eu uso o hibernate 3.3.

"

[quote=marcosalex]É a velha história dos prós e contras. Muita gente defende que tem de usar somente as APIs do JPA pra camada ficar independente do framework.

Mas pelo menos nos meus projetos o risco de eu ter de mudar a camada de persistencia é quase zero. O que ganho na produtividade com o Hibernate compensa os riscos de desenvolver outra DAO[/quote]

As únicas pessoas que eu vejo por aí que não estão usando o Hibernate são as acham mais fácil configurar o TopLink que vem todo num jar só ou que são obrigados a usar ferramentas Oracle. Deixar de usar uma solução comprovada como o Hibernate pra atirar no escuro no TopLink é risco demais pra ter quase nada em retorno.

E mesmo assim. Uma classe DAO bem escrita pode isolar o Hibernate e dar a liberdade para que caso mude a camada de persistencia mudar apenas ali.

É exatamente como eu faço.

Nunca usei JPA + Hibernate. Sempre optei por um ou por outro, os dois juntos nunca.

E mesmo assim. em 99,99999999999% dos projetos você não precisa mudar seu mecanismo de persistência, uma vez que o Hibernate foi adotado.

Você anota suas classes usando @Entity, @Table, @Column, @Id e etc?
Você persiste seus objetos usando Session e/ou usa Criteria?

Caso você responda sim às duas perguntas, você usa sim JPA + Hibernate.

Sim. A partir das ultimas versões do hibernate eles mudaram para usarem as anotações de javax.transaction e não org.hibernate.

A unica diferença é como criamos a Session.

@tnaires
Voce só pode usar como argumento a Criteria agora no lançamento da JPA 2.0. Até semana passada isso não era um argumento válido.

Talvez ainda seja válido, pois pelo que foi exposto aqui a Criteria do JPA 2.0 será sintaticamente diferente do atual Criteria do Hibernate.

Criteria já deveria ter vindo desde o JPA 1.0, agora além de melhorar o JPA, JSF tem que vir sem XML tbm para melhorar os padrões Sun, pq se for pegar wicket ou Vraptor e Hibernate vc tem mtooooo ganho com tudo q nao tem na Spec. :smiley:

Talvez ainda seja válido, pois pelo que foi exposto aqui a Criteria do JPA 2.0 será sintaticamente diferente do atual Criteria do Hibernate.[/quote]

Pelo contrario… voce disse que se voce usa a Session e o Criteria voce já usa o JPA + Hibernate.

Mas voce nao podia usar o Criteria antes da versão 2.0 da JPA. Isso que eu quis dizer que o seu argumento não é valido (Até lançamento da JPA 2.0)

[quote=Sergio Lopes][quote=Mauricio Linhares]Geradores de código denovo? Não fugimos exatamente disso no EJB antigo? Será que ninguém desses spec leaders aprende?

Santa tartaruga, Watson![/quote]

eu to concordando com vc… geracao de codigo, por mais automatica que seja, nunca foi uma boa ideia.
acho q vou continuar com minhas strings na jpa2 :)[/quote]

Felizmente discordo! :stuck_out_tongue:

Em minha opinião geração de código está voltando com força. Até onde sei sobre as “type safe criterias”, acredito que usarão o APT para gerar código em tempo de compilação. É bem provavel que os metamodelos que deixam de ser necessários devido a refatoração serão eliminados em tempo de compilação. Isso irá causar erros de compilação e seu metamodelo estará sempre sincronizado.

Essa abordagem já vem sendo usado em algumas api’s para criar type safe queries em java.

Acho que a afirmação de que estão voltando a cometer erros do passado por utilizar geração de código um tanto exagerado. Vejam Spring Roo, MDSD, JPA 2.0, APT, oAW (xtext) entre outros. Geração de código está sendo repensado e vai trazer bons frutos, assim espero! :wink:

[quote=Thiago Senna][quote=Sergio Lopes][quote=Mauricio Linhares]Geradores de código denovo? Não fugimos exatamente disso no EJB antigo? Será que ninguém desses spec leaders aprende?

Santa tartaruga, Watson![/quote]

eu to concordando com vc… geracao de codigo, por mais automatica que seja, nunca foi uma boa ideia.
acho q vou continuar com minhas strings na jpa2 :)[/quote]

Felizmente discordo! :stuck_out_tongue:

Em minha opinião geração de código está voltando com força. Até onde sei sobre as “type safe criterias”, acredito que usarão o APT para gerar código em tempo de compilação. É bem provavel que os metamodelos que deixam de ser necessários devido a refatoração serão eliminados em tempo de compilação. Isso irá causar erros de compilação e seu metamodelo estará sempre sincronizado.

Essa abordagem já vem sendo usado em algumas api’s para criar type safe queries em java.

Acho que a afirmação de que estão voltando a cometer erros do passado por utilizar geração de código um tanto exagerado. Vejam Spring Roo, MDSD, JPA 2.0, APT, oAW (xtext) entre outros. Geração de código está sendo repensado e vai trazer bons frutos, assim espero! ;)[/quote]

Tenho que concordar com o Senna, ele me provou que a geração de código dependendo muito do contexto do projeto vale a pena, mas essa idéia na comunidade em geral não está muito madura, mas não acho ruim a geração de códigos.

Eu falei que, se você usa annotations e usa o Session, Criteria ( do Hibernate ) e correlatos, você usa Hibernate + JPA.

Ahh sim…

miss…

Apesar que de certa forma a JPA foi baseada no Hibernate então voce sempre esteve usando o Hibernate.

Em primeiro lugar, Paulo obrigado pela citação.

É normal que toda mudança gere receio. Eu ainda estou digerindo as apresentadas na terceira edição do Falando em Java.

Preciso ler o post do King novamente e o post da Linda para me posicionar a respeito. Pretendo fazer isso neste fds.

Bem pessoal,

Pelo pouco que usei o JPA eu vi que ele possui um grande potencial. O que mais gostei nele é a possibilidade de pode trocar a implementação de persistência, pode usar tanto Hibernate, TopLink ou qualquer outro framework similar. Eu sempre gostei do Hibernate. Usando JPA não estarei deixando de usar ele.

Usar o mecanismo para acessar os objetos do hibernate como mostrado abaixo. Acho que também e completamente aceitavel desde que você implemente uma interface para encapsular este uso.

[code] EntitityManager em;

HibernateEntityManager ehm;

this.ehm = (HibernateEntityManager)em;
[/code]

"