Sem duvida a JPA é uma das especificações mais queridas pelos desenvolvedores, em especial pela sua proximidade ao hibernate, facilidade de uso e poder. O capítulo 6 define a tão esperada Criteria, herdada do hibernate, porém com mudanças pensando em maximizar a característica de “fluent interface”. Gavin King adicionou uma forma de poder dar type safety não só para o resultado da criteria, mas sim para todo o processo de criação da criteria. Isso vai permitir que um código como:
Repare a ausencia das aspas… essas palavras não são Strings. Obviamente as variáveis produto (de onde gerariamos a query, ai ausente), preco e data precisarão ser incializadas. Como elas definem o metamodelo, podem e devem ser cacheadas (por uma questao ate de repeticao de codigo)… Para evitar essa repetição eles sugerem o uso da geração de código, onde uma classe será produzida de alguma forma para guardar uma série de constantes. O mesmo recurso é usado para joins e afins.
Algumas pessoas podem nao gostar da ideia, e preferir a maneira mais pratica “string oriented”, e a API ainda permite isso.
minha duvida é se gero o metamodelo bizarro isso nao me adianta em nada em relacao a refactoring, certo?
as unicas vantagens seria ter ctrl+espaco na hora de escrever os atributos e o compilador verificando o metamodelo pra mim, isso?
alias nao eh pq a criteria usando o metamodelo compilou q ela esta correta, uma vez q meu metamodelo pode estar out-of-sync com o modelo…
e seria tão mais facil se adicionassem suporte a referencia de Method e Field na linguagem (assim como Class)!!
Eu achava que a ferramenta de geração fosse um “hook” (não sei o nome correto, acho que é “agent”) disponível no javac. E que uma compilação simples com alguns parâmetros a mais fosse o suficiente para gerar os metamodelos. Mas posso estar enganado, isso é correto?
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.
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]
Mas o hibernate tem funcionalidades a mais, esse é o ponto. Alem da API um pouco diferente que pode agradar mais a alguns…
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]
Vai ver ele está usando a versão anterior ao hibernate 3.
Beleza, Criteria no JPA agora sim ficou muito bom. Eu tinha implementado minha propria criteria para o JPA. Vou ver como ficou, e ver se deixou minha implementação e passar a usar a do JPA.
E se quiser usar essas funcionalidadades como por exemplo acesso a Session direta do Hibernate basta fazer um cast no seu EntitityManager usando a implementação do Hibernate:
