Qual a importancia de se utilizar JPA ao invés de Hibernate?

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

Eu falei que nao tinha outro.. nao tinha outro bom.. ou que fizesse a mesma coisa... que o hibernate

Já tentei trabalhar com esses outros..mas eles pecam mais do que o hibernate ainda.. nao gostei...

Acho que entao a filosofia de se construir o JPA teria que ser diferente... partindo de uma interface bem pensada.. e nao de implementacoes...

Voce tem que programar para interfaces.. concordo plenamente.. mas e se a interface é ruim?!

O JPA em si é valido.. como tá sendo feito é que eu acho que nao é...

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

Eu mesmo já pensei numa especificacao de um framework de persistencia.. muito mais flexivel que o hibernate por exemplo...

Se o JPA se limitar ao que o Hibernate faz.. nao vai adiantar nada..

This message was edited 1 time. Last update was at 17/03/2010 01:05:24

já leu sobre o JPA 2 ?

a especificação na verdade é um ponto de convergencia....

dificlmente uma especificação vai correr a frente da implementação.... afinal novas ideias aparecem o tempo todo... e a especificação é um conjunto das melhores.... e tenta reunir tudo em um sento comum e ponto comum....

realmente tem loucuras de bancos legados que é foda de fazer com JPA e da dor de cabeça.... e vc acaba usando anotações do Hiberante.... mas no geral, pra anotaçõeso JPA cobre tudo.... desde que não seja um banco maluco legado...

...........

Para buscas, eu não troco os Criterias pelas HQLs do JPA, mas também não exponho elas para meu projeto, e uso objetos Queries, para meu projeto não tercontato com o Hiberante, e sim com uma interface de mais alto nivel....

assim posso continuar reusando.... por exemplo, trocar do Hiberante 3 para a proxima versão que vai implementar o JPA 2, vai ser relativamente fácil para meus projetos, pois só vou reescrever a camada de persistencia, um conjunto de 8 classes no máximo.

Lógico que não vou pegar meu projeto que ta escrito com criterias 3.x, e com hiberante e etc, e enfiar o Hibernate novo para JPA 2, pq isso seria sem sentido... porem vou conseguir reusuar a mesma lógica em novos projetos, sem ser afetado pela camada de persistencia...

..........

Obs.: eu entendo sua revolta... já pensei igual, mas me ajudar muito, conseguir não programar diretamente com o hiberante....

aqui vai um exemplo de código em meus projetos...

todas são de facil leitura, Repository éuma INterface.... e a implementação normal que uso é pra Hiberante.... mas já precisei usar pra SQL puro entre outras firulas, por questões diversas

..........

em momento algum em meu projeto há um new HibernateRepository .... quando não uso algo como spring, o HiberanteRepository vem sempre de algo como

Repository repository = minhaFabrica.createRepository();

no caso é só trocar o que vem do CreateRepository e voala! .... mudo a implementação facilmente...

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

Muito legal cara.... to vendo que voce é um cara conhecedor do assunto...

Fiquei curioso sobre o Repository... tem algum artigo interessante sobre isso?

Procurei na internet mas só vi gente perguntando sobre a diferença entre repository e dao e poucas explicacoes....

eu iniciei lendo no blog do sergio taborda http://sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/repository/

depois fui fazendo a minha maneira....

A entender, a diferenca basica do DAO pro RESPOSITORIO, e' que o DAO acumla as queries dentro dele, e por isso vc sai criando 1 DAO por Entidade.... isso traz dificuldade, pois uma Session funciona com um repositorio, ela funciona igual seja a entidade qual for.........

Entao o repositorio tem aceita objetos em seus metodos, e asism repository.add(Object o); e assim para cada operacao,

Tudo que for generico vc deixa no repositorio, ou seja

<T> List<T> repo.list(Class<T> target);
<T> T repo.get(Class<T> target, Object id);
repo.refresh(Object object);

etc etc etc

e as queries as consultas, vc separa coloca em outro objeto, eu crirei uma interface pra fazer isso...

e no fim, eu executo uma Query em um Repository,

que para o hiberante eu so faco pegar um DatechedCriteria que esta dentro do queries, e unir a session dentro do repository, e assim a magica da consulta acontece...

This message was edited 2 times. Last update was at 17/03/2010 11:36:13

Ótimo tópico, não vejo grandes diferenças não, como já falado anteriormente acho bacana a Sun trazer algo de sucesso para especificação...

A JPA por se tratar de uma abstração que funciona independente de uma implementação específica te permite
ter alternativas ao Hibernate(claro que a implementação dele é a melhor entre outras), te possibilitando uma flexibilidade de escolha, acho isto um quesito muito importante quando se trabalha com boas práticas de OO...

Como já falado, outro obstaculo a JPA seria o Criteria, mas já foi inserido na especificação 2.0 com alguns recursos de tipagem não existentes no Hibernate...

Rogel deixa de ser chato e teimoso e usa o JPA...

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

Hahahah... blza Breno...

Só estou estressando as possibilidades para ver qual é a melhor alternativa..

Se vou usar alguma coisa.. tenho que ter motivos para isso... to procurando os motivos...

Não gosto de usar alguma coisa só pq um povo que nem programa no dia a dia definiu.. (já vi muitas definicoes ruins desse pessoal)

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

Vejamos esse mapeamento (eliminei os getters e setters para simplificar):

Isso poderia ser feito assim:

Todas as informações do mapeamento já estão na classe...
Eu poderia configurar no meu persistence.xml
Todos as classes do pacote com.company.persistence são entidades
Os atributos com nome id são @Id
Todos os @id devem usar um sequence com nome sq_{nomedaclasse}
É óbvio que Tipo é um @ManyToOne.. e poderia definir que todos os @ManyToOne são lazy

Pronto.. eu configuraria meu padrão uma vez na minha app.. e não precisaria lotar minha classe com anotations.. isso sim.. é uma coisa prática.. que ajuda no sistema e diminui o acoplamento

Agora o povo fica só pensando em coisas do reino da imaginacao que no dia a dia nem tem tanta importancia

Lavieri

poderia explicar melhor esta estrutura:

pelo que eu entendi queries é uma classe onde vc pode pegar objetos de consulta especificos de cada classe do mdoelo, no caso o forPessoa retorna um desses objetos pra classe Pessoa. nesses objetos estão as queries especificas de pessoas, como no exemplo listPessoasAtivas. só não entendi o que esse query on retorna, acho que é um obejto que sabe qual query a ser executada no repositório, mas não estou com certeza disso.

Achei muito bacana, quero entender pra montar algo do tipo.

[]'s

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

Outra coisa...

Imagine que eu tenho a classe Mestre e a classe mestre tenha uma List de Detalhe

Se eu anotar os detalhes com aqueles cascades todos.. pra ficar tudo automático...

Como eu faço se eu quiser alterar só o Mestre e não quiser mecher nos Detalhes? Se eu mandar persistir o Mestre sem Detalhe nenhum (lista vazia).. o JPA/Hibernate vai apagar todos os meus detalhes..

rogelgarcia wrote:Outra coisa...

Imagine que eu tenho a classe Mestre e a classe mestre tenha uma List de Detalhe

class Mestre { List<Detalhe> detalhes; }

Se eu anotar os detalhes com aqueles cascades todos.. pra ficar tudo automático...

Como eu faço se eu quiser alterar só o Mestre e não quiser mecher nos Detalhes? Se eu mandar persistir o Mestre sem Detalhe nenhum (lista vazia).. o JPA/Hibernate vai apagar todos os meus detalhes..

Bom, com o que vc tem hj tem como fazer apenas de forma estática, insertable = false ...

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

rogelgarcia wrote:Outra coisa...

Imagine que eu tenho a classe Mestre e a classe mestre tenha uma List de Detalhe

class Mestre { List<Detalhe> detalhes; }

Se eu anotar os detalhes com aqueles cascades todos.. pra ficar tudo automático...

Como eu faço se eu quiser alterar só o Mestre e não quiser mecher nos Detalhes? Se eu mandar persistir o Mestre sem Detalhe nenhum (lista vazia).. o JPA/Hibernate vai apagar todos os meus detalhes..

Não entendi o cenário. Pq detalhes esta vazio? Ele poderia estar com o proxy Lazy de sua representação no banco, e vc alterar os outros atributos de Mestre normalmente. Uma coisa não tem haver com outra.

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

Eu poderia estar com um Mestre desatachado da sessao.. que eu quisesse persistir... (mas a lista de Detalhe está vazia)

Eu gostaria de só alterar o Mestre.. mas se eu pedir pra salvar o Mestre desse jeito.. o hibernate também deleta o detalhe...

This message was edited 1 time. Last update was at 17/03/2010 13:45:52

Tem vários motivos para vc iniciar um projeto com JPA, a maioria já foi explanado aqui, mas vamos lá:

- Bootstrap facilitado: HibernateUtil é um "workaround" necessário para se construir a SessionFactory. Já vi muita implementação meia boca estourando memória por causa disso. O JPA em ambiente JavaEE é bem mais eficiente em sua inicialização com o apoio do persistence.xml, autodiscovery das classes anotadas e gerencia do EntityManager feita automaticamente pelo container (abri, fechar, descarregar e injetar).

- D.I. - Uma vez fazendo parte da especificação, ele se beneficia de todos os demais recursos enterprises, sobre injeção de dependencia e todo seu ciclo de vida. No JavaEE 6, isso esta ainda melhor, uma vez que não apenas EJBs podem se beneficiarem com isso, mas qualquer bean.

- Portabilidade (menos relevante) - nao considero isso a melhor feature para iniciar um projeto com JPA, pq EU utilizao muita coisa do Hibernate. Mas para quem preza por independecia de implementação pode ser um atrativo.

O fato é, 99,9% das vezes inicio os projetos com JPA. Quando algo nao me atende entao getDelegate para obter a session do hibernate, sem pestanejar. Mas nao perco a integração com o ambiente JavaEE e nem seu bootstrap que é uma mao na roda.

This message was edited 1 time. Last update was at 17/03/2010 13:52:08

rogelgarcia wrote:Eu poderia estar com um Mestre desatachado da sessao.. que eu quisesse persistir... (mas a lista de Detalhe está vazia)

Eu gostaria de só alterar o Mestre.. mas se eu pedir pra salvar o Mestre desse jeito.. o hibernate também deleta o detalhe...

Mas "PQ" detalhe esta vazia???
Se Mestre esta detachado e vc faz "Merge", ele nao apaga sua lista, ele relinka os proxies de Detalhe, que NAO esta vazio.
A não ser que vc tenha construído o Mestre com "new", o que nao deveria ser feito.

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