Alguma desvantagem do uso do Hibernate EntityManager (vs. Hibernate Core)?

Question

A documentação do Hibernate EntityManager estados, este:

Você pode usar uma combinação de todos os três juntos, anotações sem interfaces de programação JPA e ciclo de vida, ou mesmo núcleo de hibernato nativo puro, dependendo das necessidades comerciais e técnicas do seu projeto. Você sempre pode voltar a hibernar as APIs nativas, ou se necessário, mesmo para o JDBC e o SQL nativos.

O código que usa a API JPA (EntityManager) é claramente mais portátil (mesmo com fallbacks ocasionais para hibernar o núcleo).

Mas eu teria alguma vantagem ao usar o núcleo puramente hibernado? Gostaria de saber se o modelo JPA 2 realmente se encaixa no núcleo do hibernato sem nenhuma contradição? Iow, é sempre fácil e sem problemas?

Minha principal preocupação é a seguinte:

Talvez as diferenças não estejam apenas na API, mas também no subjacente semântica?! (por exemplo, diferentes semânticas de transação/versão/bloqueio que podem conflitar: o bloqueio pessimista é mencionado na documentação principal, mas não na documentação do entityManager - então eu ainda poderia usar o bloqueio pessimista voltando ao núcleo sem causar problemas? Coisas assim .. .)

Answer 1

Mas eu teria alguma vantagem ao usar o núcleo puramente hibernado?

Se o JPA 2.0 suporta o que você precisa, não há na minha opinião vantagem em usar o núcleo do Hibernate diretamente (e com o JPA 2.0, a lacuna se tornou mais fina, tornando a necessidade de fallback para o núcleo da exceção, não a regra, que é um muito coisa boa).

Gostaria de saber se o modelo JPA 2 realmente se encaixa no núcleo do hibernato sem nenhuma contradição?

Desde que o JPA 1.0, os desenvolvedores de hibernato criaram o Hibernate3 com "JPA em mente" e adotaram a semântica JPA, padrões, etc. no Hibernate3. Você pode querer ouvir Gavin nisso Talk Tech: Gavin King no Hibernate3 e EJB3:

Nesta palestra de tecnologia, King discute Como o Hibernate3 se baseia e estende EJB3, abordando tópicos como:

• Novos recursos do Hibernate3
• A relação entre Hibernate3 e o contêiner EJB3 em JBoss
• O que diferencia o Hibernate3 da especificação EJB3
• Anotações personalizadas do Hibernate disponíveis fora do EJB
• O futuro do hibernado

E de acordo com minha experiência prática, o fato de o Hibernate não contradizer com o EJB 3 é verdadeiro.

Iow, é sempre fácil e sem problemas?

Se você usa o núcleo diretamente ou não, você são usando -o (o EntityManager é um invólucro ao redor do Session). Então, sim, voltar ao núcleo é fácil se você realmente precisar (para coisas que ainda não estão na especificação como consulta por exemplo, por exemplo). E, não, isso não causará problemas (já que você realmente o está usando, ou um subconjunto dele, no JPA).

Perguntas relacionadas

• Diferença Hibernate 3.5 / JPA 2.0

Answer 2

Ficou claro: dependendo dos negócios e necessidades técnicas do seu projeto

Mas eu teria alguma vantagem ao usar o núcleo puramente hibernado?

Não se esqueça das anotações de hibernação e do Hibernate EntityManager é construído sobre o núcleo do hibernato. Então, mais uma camada. Além disso, ele depende de seus metadados de mapeamento armazenados nos arquivos XML. Alguns usuários preferem usar arquivos XML em vez de anotações, pois deixa os objetos de domínio completamente independentes da implementação DAO que você escolher. Mas ao usar anotações, o Hibernate With JPA é claro

Reduza suas linhas de código para o mapeamento de metadados, em comparação com os arquivos XML nativos, e você pode gostar dos melhores recursos de refatoração de anotações

JDBC >> Hibernate core >> Hibernate Annotations

...

JDBC >> Hibernate core >> Hibernate EntityManager

E o JPA 2 se encaixa melhor no que o JPA 1 não foi fornecido. Muitos recursos novos já estão disponíveis, como

• API de consulta orientada a objetos
• Wrapper's @Embeddable
• Coleção de @embeddables @ElementCollection

E assim por diante...

Não se esqueça getDelegate Método se você precisar de recursos onde o JPA não fornece.

Answer 3

Eu gosto de usar o núcleo de hibernato diretamente. Eu também prefiro arquivos de mapeamento XML.

Não estou realmente interessado em usar uma camada secundária, para acessar a funcionalidade principal do Hibernate. No que me diz respeito à portabilidade no nível de persistência, é um completo não emissão.

Existem muito poucas vantagens reais da API da JPA sobre a API de hibernação - vi pessoas usando consultas nomeadas JPA (onde os critérios provavelmente teriam sido mais claros e melhores), e as anotações da JPA são um pouco mais bem projetadas.

Fora isso, o JPA é apenas uma camada que adiciona complexidade e sobrecarga potencial - sem nenhum benefício. Arquitetonicamente, nessa situação, a decisão correta seria contra usá -la.

Portabilidade do banco de dados OTOH é muito real. Tenho alocadores personalizados (geradores) que são completamente portáteis, e muito mais performance e mais simples do que a bagunça maluca, que é a hibernada mal projetada.

Essa abordagem foi muito bem-sucedida em vários projetos de reengenharia comerciais, de bancos de dados do Governamental e Legados. Em resumo - concentre -se no que é importante - e uma API em cima de uma API, não é isso.

Answer 4

Os benefícios de usar a API JPA superam em muito quaisquer desvantagens do uso de hibernato puro. Não sou especialista, mas não conheço nenhuma situação em que seria benéfico descer para Hibernate. (Cair para fazer o JDBC puro é uma questão diferente.)

Se alguém tiver algum exemplo para compartilhar, eu adoraria vê -los.