Hibernate vs JPA vs JDO - prós e contras de cada um? [fechadas]

Estou familiarizado com o ORM como um conceito e até usei o nHibernate há vários anos para um projeto .NET; no entanto, não acompanhei o tópico do ORM em Java e não tive a chance de usar nenhuma dessas ferramentas.

Mas agora posso ter a chance de começar a usar algumas ferramentas ORM para um de nossos aplicativos, na tentativa de me afastar de uma série de serviços da web legados.

Estou tendo dificuldade em dizer a diferença entre as especificações da JPA, o que você obtém com a própria biblioteca Hibernate e o que o JDO tem a oferecer.

Então, eu entendo que essa pergunta é um pouco aberta, mas eu esperava obter algumas opiniões sobre:

• Quais são os prós e os contras de cada um?
• O que você sugeriria para um novo projeto?
• Existem certas condições em que faria sentido usar uma estrutura versus a outra?

Algumas notas:

• JDO e JPA são especificações, não implementações.
• A idéia é que você pode trocar implementações de JPA, se você restringir seu código para usar apenas JPA padrão. (Idem para JDO.)
• O Hibernate pode ser usado como uma dessas implementações da JPA.
• No entanto, o Hibernate fornece uma API nativa, com recursos acima e além do JPA.

OMI, eu recomendaria o Hibernate.

Houve alguns comentários / perguntas sobre o que você deve fazer se precisar usar recursos específicos do Hibernate. Existem várias maneiras de analisar isso, mas meu conselho seria:

• Se você não estiver preocupado com a perspectiva de vínculo com o fornecedor, faça sua escolha entre o Hibernate e outras implementações JPA e JDO, incluindo as várias extensões específicas do fornecedor em sua tomada de decisão.

• Se você está preocupado com a perspectiva de vínculo com o fornecedor e não pode usar o JPA sem recorrer a extensões específicas do fornecedor, não use o JPA. (Idem para JDO).

Na realidade, você provavelmente precisará negociar o quanto está preocupado com o vínculo com o fornecedor e o quanto precisa dessas extensões específicas do fornecedor.

E também existem outros fatores, como quão bem você / sua equipe conhece as respectivas tecnologias, quanto os produtos custarão no licenciamento e cuja história você acredita sobre o que acontecerá no futuro para a JDO e a JPA.

Certifique-se de avaliar a implementação do JDO DataNucleus. Começamos com o Hibernate porque parecia muito popular, mas logo percebemos que não era uma solução de persistência 100% transparente. Existem muitas advertências e a documentação está cheia de 'se você tiver essa situação, deverá escrever seu código como este', o que tirou a diversão de modelar e codificar livremente da maneira que desejamos. O JDO nunca me levou a ajustar meu código ou modelo para fazê-lo "funcionar corretamente". Posso apenas projetar e codificar POJOs simples como se fosse usá-los 'na memória' apenas, mas posso persistir com transparência.

A outra vantagem do JDO / DataNucleus sobre o hibernate é que ele não possui sobrecarga de reflexão em todo o tempo de execução e é mais eficiente em memória porque usa aprimoramento do código de byte do tempo de construção (talvez adicione 1 segundo ao tempo de construção para um projeto grande) do que o padrão de proxy ativado por reflexão do tempo de execução do hibernate.

Outra coisa que você pode achar irritante com o Hibernate é que uma referência que você tem ao que você acha que é o objeto ... geralmente é um 'proxy' para o objeto. Sem o benefício do aprimoramento do código de bytes, o padrão de proxy é necessário para permitir o carregamento sob demanda (ou seja, evite puxar todo o gráfico de objetos ao puxar um objeto de nível superior). Esteja preparado para substituir códigos iguais e hash, porque o objeto que você pensa que está referenciando geralmente é apenas um proxy para esse objeto.

Aqui está um exemplo de frustrações que você obterá com o Hibernate e que não obterá com o JDO:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Se você gosta de codificar para 'soluções alternativas', certamente, o Hibernate é para você. Se você aprecia um desenvolvimento limpo, puro, orientado a objetos e orientado a modelos, onde gasta todo o seu tempo em modelagem, design e codificação e nada disso em soluções alternativas feias, passe algumas horas avaliando o JDO / DataNucleus . As horas investidas serão reembolsadas mil vezes.

Atualização fevereiro de 2017

Por algum tempo, o DataNucleus 'implementa o padrão de persistência JPA, além do padrão de persistência JDO, portanto, a portabilidade dos projetos JPA existentes do Hibernate para o DataNucleus deve ser bastante direta e você pode obter todos os benefícios mencionados acima do DataNucleus com muito pouca alteração de código. , caso existam. Portanto, em termos de pergunta, a escolha de um padrão específico, JPA (somente RDBMS) vs JDO (RDBMS + Sem SQL + ODBMSes + outros), o DataNucleus suporta ambos, o Hibernate é restrito apenas ao JPA.

Desempenho das atualizações do banco de dados Hibernate

Outra questão a considerar ao escolher um ORM é a eficiência de seu mecanismo de verificação suja - que se torna muito importante quando é necessário construir o SQL para atualizar os objetos que foram alterados na transação atual - especialmente quando há muitos objetos. Há uma descrição técnica detalhada do mecanismo de verificação suja do Hibernate nesta resposta do SO: JPA com inserção HIBERNATE muito lenta

Avaliei recentemente e escolhi uma estrutura de persistência para um projeto java e minhas descobertas são as seguintes:

O que estou vendo é que o apoio a favor da JDO é principalmente:

• você pode usar fontes de dados não-sql, db4o, hbase, ldap, bigtable, couchdb (plugins para cassandra) etc.
• você pode alternar facilmente de uma fonte de dados sql para não-sql e vice-versa.
• nenhum objeto proxy e, portanto, menos problemas com relação às implementações hashcode () e equals ()
• mais POJO e, portanto, menos soluções alternativas necessárias
• suporta mais tipos de relacionamento e campo

e o apoio a favor da JPA é principalmente:

• mais popular
• jdo está morto
• não usa aprimoramento de bytecode

Estou vendo muitas postagens pró-JPA de desenvolvedores de JPA que claramente não usaram o JDO / Datanucleus oferecendo argumentos fracos por não usar o JDO.

Também estou vendo muitas postagens de usuários do JDO que migraram para o JDO e são muito mais felizes como resultado.

Quanto à JPA ser mais popular, parece que isso se deve em parte ao suporte do fornecedor do RDBMS, em vez de ser tecnicamente superior. (Parece VHS / Betamax para mim).

O JDO e seu Datanucleus de implementação de referência claramente não estão mortos, como mostra a adoção do Google pelo GAE e desenvolvimento ativo no código-fonte (http://sourceforge.net/projects/datanucleus/).

Vi várias reclamações sobre o JDO devido ao aprimoramento do bytecode, mas ainda não há explicação para o motivo.

De fato, em um mundo que está ficando cada vez mais obcecado pelas soluções NoSQL, o JDO (e a implementação do datanucleus) parece uma aposta muito mais segura.

Acabei de começar a usar o JDO / Datanucleus e o configurei para que eu possa alternar facilmente entre o uso do db4o e o mysql. É útil para o desenvolvimento rápido usar o db4o e não precisar se preocupar muito com o esquema do banco de dados; depois, quando o esquema estiver estabilizado para implantar em um banco de dados. Também me sinto confiante de que, mais tarde, eu poderia implantar toda / parte do meu aplicativo no GAE ou aproveitar o armazenamento distribuído / reduzir o mapa a la hbase / hadoop / cassandra sem muita refatoração.

Achei um pouco complicado começar com o Datanucleus - a documentação no site do datanucleus é um pouco difícil de entender - os tutoriais não são tão fáceis de seguir quanto eu gostaria. Dito isto, a documentação mais detalhada sobre a API e o mapeamento é muito boa quando você passa pela curva de aprendizado inicial.

A resposta é: depende do que você deseja. Prefiro ter opções nosql de código mais limpo, sem fornecedor-lock-in, mais orientado a pojo e versos mais populares.

Se você deseja a sensação agitada de estar fazendo o mesmo que a maioria dos outros desenvolvedores / ovelhas, escolha JPA / hibernate. Se você quer liderar em seu campo, teste o JDO / Datanucleus e faça sua própria decisão.

O que você sugeriria para um novo projeto?

Eu também não sugeriria! Use Spring DAO's JdbcTemplatejunto com StoredProcedure, RowMappere em RowCallbackHandlervez disso.

Minha experiência pessoal com o Hibernate é que o tempo economizado antecipadamente é mais do que compensado pelos intermináveis ​​dias que você passará na fila tentando entender e depurar problemas como um comportamento inesperado de atualização em cascata.

Se você estiver usando um banco de dados relacional, quanto mais próximo seu código estiver, mais controle você terá. A camada DAO do Spring permite um controle fino da camada de mapeamento, enquanto elimina a necessidade de código padrão. Além disso, ele se integra à camada de transações do Spring, o que significa que você pode facilmente adicionar (via AOP) um comportamento transacional complicado sem que isso se intrometa no seu código (é claro, você também obtém isso no Hibernate).

JDO está morto

Como o JDO não está morto, verifique seus fatos. O JDO 2.2 foi lançado em outubro de 2008. O JDO 2.3 está em desenvolvimento.

Isso é desenvolvido abertamente, no Apache. Mais lançamentos do que o JPA, e sua especificação ORM ainda está adiantada, mesmo dos recursos propostos pelo JPA2

O JDO possui recursos avançados que o JPA, consulte http://db.apache.org/jdo/jdo_v_jpa.html

Estou usando o JPA (implementação OpenJPA do Apache, que é baseada na base de código KODO JDO, que tem mais de 5 anos e é extremamente rápida / confiável). IMHO quem disser para ignorar as especificações está dando um mau conselho. Eu dediquei o tempo e fui definitivamente recompensado. Com o JDO ou o JPA, é possível alterar os fornecedores com alterações mínimas (o JPA possui mapeamento orm, portanto, estamos falando menos de um dia para possivelmente mudar de fornecedor). Se você tiver mais de 100 mesas como eu, isso é enorme. Além disso, você obtém o cache built-in com despejos de cache em cluster e tudo é bom. O SQL / Jdbc é adequado para consultas de alto desempenho, mas a persistência transparente é muito superior para escrever seus algoritmos e rotinas de entrada de dados. Eu só tenho cerca de 16 consultas SQL em todo o meu sistema (mais de 50k linhas de código).

Eu estive investigando isso sozinho e não consigo encontrar uma forte diferença entre os dois. Eu acho que a grande escolha é em qual implementação você usa. Para mim, estive considerando a plataforma DataNucleus , pois é uma implementação independente de armazenamento de dados de ambas.

Quem diz que JDO está morto é um vendedor de FUD para astroturismo e sabe disso.

JDO está vivo e bem. A especificação ainda é mais poderosa, madura e avançada do que a JPA muito mais jovem e restrita.

Se você deseja limitar-se apenas ao que está disponível no padrão JPA, pode gravar no JPA e usar o DataNucleus como uma implementação de persistência mais transparente e de alto desempenho do que as outras implementações do JPA. É claro que o DataNucleus também implementa o padrão JDO se você deseja a flexibilidade e a eficiência da modelagem que o JDO traz.

Eu usei o Hibernate (implementação JPA) e JPOX (implementação JDO) no mesmo projeto. O JPOX funcionou bem, mas encontrou erros rapidamente, onde alguns recursos da linguagem Java 5 não eram compatíveis no momento. Ocorreu um problema ao executar o bom funcionamento com transações XA. Eu estava gerando o esquema do banco de dados a partir dos objetos JDO. Ele queria se conectar a um banco de dados toda vez que é irritante se a sua conexão Oracle não estiver funcionando.

Em seguida, mudamos para o Hibernate. Brincamos com o uso de JPA puro por um tempo, mas precisamos usar alguns dos recursos específicos do Hibernate para fazer o mapeamento. Executar o mesmo código em vários bancos de dados é muito fácil. O Hibernate parece armazenar objetos em cache de maneira agressiva ou, às vezes, apresenta um comportamento estranho de armazenamento em cache. Existem algumas construções DDL que o Hibernate não pode manipular e, portanto, são definidas em um arquivo adicional que é executado para inicializar o banco de dados. Quando me deparei com um problema de hibernação, muitas vezes há pessoas que se deparam com o mesmo problema, o que facilita a busca de soluções no Google. Finalmente, o Hibernate parece ser bem projetado e confiável.

Alguns outros respondedores sugeriram apenas o uso de SQL. O verdadeiro caso de uso matador para o mapeamento relacional de objetos é teste e desenvolvimento. Os bancos de dados criados para lidar com grandes volumes de dados geralmente são caros e são difíceis de instalar. Eles são difíceis de testar. Há muitos bancos de dados Java na memória que podem ser usados ​​para teste, mas geralmente são inúteis para produção. Ser capaz de usar um banco de dados real, mas limitado, aumentará a produtividade do desenvolvimento e a confiabilidade do código.

Fiz uma amostra do WebApp em maio de 2012 que usa o JDO 3.0 e o DataNucleus 3.0 - veja como está limpo: https://github.com/TorbenVesterager/BadAssWebApp

Ok, talvez seja um pouco limpo demais, porque eu uso os POJOs tanto para o banco de dados quanto para o cliente JSON, mas é divertido :)

PS: Contém algumas anotações do SuppressWarnings (desenvolvidas no IntelliJ 11)