Hibernate vs JPA vs JDO - avantages et inconvénients de chacun? [fermé]

Je connais ORM en tant que concept, et j'ai même utilisé nHibernate il y a plusieurs années pour un projet .NET; cependant, je n'ai pas suivi le sujet de l'ORM en Java et je n'ai eu la chance d'utiliser aucun de ces outils.

Mais, maintenant, j'ai peut-être la chance de commencer à utiliser certains outils ORM pour l'une de nos applications, dans le but de m'éloigner d'une série de services Web hérités.

J'ai du mal à faire la différence entre la spécification JPA, ce que vous obtenez avec la bibliothèque Hibernate elle-même et ce que JDO a à offrir.

Donc, je comprends que cette question est un peu ouverte, mais j'espérais avoir des opinions sur:

• Quels sont les avantages et les inconvénients de chacun?
• Lequel proposeriez-vous pour un nouveau projet?
• Y a-t-il certaines conditions dans lesquelles il serait logique d'utiliser un cadre par rapport à l'autre?

Quelques notes:

• JDO et JPA sont tous deux des spécifications, pas des implémentations.
• L'idée est que vous pouvez permuter les implémentations JPA, si vous limitez votre code à utiliser uniquement le JPA standard. (Idem pour JDO.)
• Hibernate peut être utilisé comme une telle implémentation de JPA.
• Cependant, Hibernate fournit une API native, avec des fonctionnalités supérieures à celles de JPA.

IMO, je recommanderais Hibernate.

Il y a eu quelques commentaires / questions sur ce que vous devriez faire si vous devez utiliser des fonctionnalités spécifiques à Hibernate. Il y a plusieurs façons de voir cela, mais mon conseil serait:

• Si vous n'êtes pas préoccupé par la perspective d'un lien avec le fournisseur, faites votre choix entre Hibernate et d'autres implémentations JPA et JDO, y compris les différentes extensions spécifiques au fournisseur dans votre prise de décision.

• Si la perspective d'un lien avec le fournisseur vous inquiète et que vous ne pouvez pas utiliser JPA sans recourir à des extensions spécifiques au fournisseur, n'utilisez pas JPA. (Idem pour JDO).

En réalité, vous devrez probablement arbitrer à quel point vous êtes inquiet du lien avec le fournisseur par rapport à combien vous avez besoin de ces extensions spécifiques au fournisseur.

Et il y a aussi d'autres facteurs, comme la connaissance par vous / votre personnel des technologies respectives, le coût des produits en licence, et l'histoire de qui vous pensez de ce qui va se passer dans le futur pour JDO et JPA.

Assurez-vous d'évaluer l'implémentation DataNucleus de JDO. Nous avons commencé avec Hibernate parce qu'il semblait si populaire, mais nous avons assez vite réalisé que ce n'était pas une solution de persistance 100% transparente. Il y a trop de mises en garde et la documentation est pleine de «si vous avez cette situation, vous devez écrire votre code comme ceci» qui vous a enlevé le plaisir de modéliser et de coder librement comme nous le voulons. JDO ne m'a jamais amené à ajuster mon code ou mon modèle pour le faire «fonctionner correctement». Je peux simplement concevoir et coder des POJO simples comme si j'allais les utiliser «en mémoire» uniquement, mais je peux les conserver de manière transparente.

L'autre avantage de JDO / DataNucleus par rapport à la mise en veille prolongée est qu'il n'a pas toute la surcharge de réflexion d'exécution et qu'il est plus efficace en mémoire car il utilise l'amélioration du code d'octet au moment de la construction (peut-être ajouter 1 seconde à votre temps de construction pour un grand projet) plutôt que le modèle de proxy alimenté par la réflexion d'exécution d'Hibernate.

Une autre chose que vous pourriez trouver ennuyeuse avec Hibernate est qu'une référence que vous avez à ce que vous pensez être l'objet ... c'est souvent un «proxy» pour l'objet. Sans l'avantage de l'amélioration du code d'octet, le modèle de proxy est nécessaire pour permettre le chargement à la demande (c'est-à-dire éviter de tirer l'intégralité de votre graphe d'objets lorsque vous insérez un objet de niveau supérieur). Soyez prêt à remplacer equals et hashcode, car l'objet que vous pensez référencer n'est souvent qu'un proxy pour cet objet.

Voici un exemple de frustrations que vous aurez avec Hibernate et que vous n'obtiendrez pas avec JDO:

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

Si vous aimez coder des «solutions de contournement», alors, bien sûr, Hibernate est fait pour vous. Si vous appréciez le développement propre, pur, orienté objet et axé sur les modèles, où vous passez tout votre temps à la modélisation, à la conception et au codage et rien de tout cela à des solutions de contournement laides, passez quelques heures à évaluer JDO / DataNucleus . Les heures investies seront remboursées mille fois.

Mise à jour février 2017

Depuis un certain temps maintenant, DataNucleus implémente la norme de persistance JPA en plus de la norme de persistance JDO.Le portage des projets JPA existants d'Hibernate vers DataNucleus devrait donc être très simple et vous pouvez obtenir tous les avantages mentionnés ci-dessus de DataNucleus avec très peu de changement de code. , si seulement. Donc en termes de question, le choix d'un standard particulier, JPA (SGBDR uniquement) vs JDO (SGBDR + Pas de SQL + ODBMS + autres), DataNucleus prend en charge les deux, Hibernate est limité à JPA uniquement.

Performances des mises à jour de Hibernate DB

Un autre problème à prendre en compte lors du choix d'un ORM est l'efficacité de son mécanisme de vérification sale - cela devient très important lorsqu'il a besoin de construire le SQL pour mettre à jour les objets qui ont changé dans la transaction en cours - en particulier lorsqu'il y a beaucoup d'objets. Il y a une description technique détaillée du mécanisme de vérification sale d'Hibernate dans cette réponse SO: JPA avec insertion HIBERNATE très lente

J'ai récemment évalué et choisi un cadre de persistance pour un projet java et mes conclusions sont les suivantes:

Ce que je constate, c'est que le soutien en faveur de JDO est avant tout:

• vous pouvez utiliser des sources de données non-sql, db4o, hbase, ldap, bigtable, couchdb (plugins pour cassandra) etc.
• vous pouvez facilement passer d'une source de données sql à non-sql et vice-versa.
• pas d'objets proxy et donc moins de douleur en ce qui concerne les implémentations de hashcode () et equals ()
• plus de POJO et donc moins de solutions de contournement requises
• prend en charge plus de types de relations et de champs

et le soutien en faveur de JPA est principalement:

• plus populaire
• jdo est mort
• n'utilise pas d'amélioration du bytecode

Je vois beaucoup de messages pro-JPA de développeurs JPA qui n'ont clairement pas utilisé JDO / Datanucleus offrant des arguments faibles pour ne pas utiliser JDO.

Je vois également beaucoup de messages d'utilisateurs de JDO qui ont migré vers JDO et qui en sont beaucoup plus heureux.

En ce qui concerne le fait que JPA soit plus populaire, il semble que cela soit dû en partie au support du fournisseur de SGBDR plutôt qu'à sa supériorité technique. (Cela ressemble à VHS / Betamax pour moi).

JDO et son implémentation de référence Datanucleus n'est clairement pas mort, comme le montre son adoption par Google pour GAE et son développement actif sur le code source (http://sourceforge.net/projects/datanucleus/).

J'ai vu un certain nombre de plaintes à propos de JDO en raison de l'amélioration du bytecode, mais aucune explication pour le moment ne explique pourquoi c'est mauvais.

En fait, dans un monde de plus en plus obsédé par les solutions NoSQL, JDO (et l'implémentation datanucleus) semble un pari beaucoup plus sûr.

Je viens de commencer à utiliser JDO / Datanucleus et je l'ai configuré pour que je puisse basculer facilement entre l'utilisation de db4o et mysql. Il est utile pour un développement rapide d'utiliser db4o et de ne pas avoir à se soucier trop du schéma de base de données, puis, une fois le schéma stabilisé, de se déployer sur une base de données. Je suis également convaincu que plus tard, je pourrais déployer tout / partie de mon application sur GAE ou profiter du stockage distribué / réduire la carte à la hbase / hadoop / cassandra sans trop de refactorisation.

J'ai trouvé l'obstacle initial pour démarrer avec Datanucleus un peu délicat - La documentation sur le site Web de datanucleus est un peu difficile à saisir - les tutoriels ne sont pas aussi faciles à suivre que je l'aurais souhaité. Cela dit, la documentation plus détaillée sur l'API et la cartographie est très bonne une fois que vous avez dépassé la courbe d'apprentissage initiale.

La réponse est que cela dépend de ce que vous voulez. Je préférerais avoir un code plus propre, pas de verrouillage du fournisseur, plus orienté vers pojo, des vers d'options nosql plus populaires.

Si vous voulez avoir le sentiment chaleureux et difficile de faire la même chose que la majorité des autres développeurs / moutons, choisissez JPA / hibernate. Si vous voulez être leader dans votre domaine, testez JDO / Datanucleus et faites-vous votre propre opinion.

Lequel proposeriez-vous pour un nouveau projet?

Je ne suggérerais ni l'un ni l'autre! Utilisez Spring DAO est JdbcTemplateainsi StoredProcedure, RowMapperet à la RowCallbackHandlerplace.

Mon expérience personnelle avec Hibernate est que le temps gagné au départ est plus que compensé par les jours interminables que vous passerez tout au long de la ligne à essayer de comprendre et de déboguer des problèmes tels que le comportement de mise à jour en cascade inattendu.

Si vous utilisez une base de données relationnelle, plus votre code s'en rapproche, plus vous avez de contrôle. La couche DAO de Spring permet un contrôle précis de la couche de mappage, tout en supprimant le besoin de code standard. En outre, il s'intègre dans la couche de transaction de Spring, ce qui signifie que vous pouvez très facilement ajouter (via AOP) un comportement transactionnel compliqué sans que cela n'interfère dans votre code (bien sûr, vous obtenez également cela avec Hibernate).

JDO est mort

JDO n'est pas mort en fait, alors vérifiez vos faits. JDO 2.2 est sorti en octobre 2008 JDO 2.3 est en cours de développement.

Ceci est développé ouvertement, sous Apache. Plus de versions que JPA n'en a eu, et sa spécification ORM est encore en avance sur les fonctionnalités proposées par JPA2

JDO a des fonctionnalités avancées que JPA voir http://db.apache.org/jdo/jdo_v_jpa.html

J'utilise JPA (implémentation OpenJPA d'Apache qui est basée sur la base de code KODO JDO qui a plus de 5 ans et est extrêmement rapide / fiable). IMHO toute personne qui vous dit de contourner les spécifications vous donne de mauvais conseils. J'ai mis du temps et j'ai été vraiment récompensé. Avec JDO ou JPA, vous pouvez changer de fournisseur avec des changements minimes (JPA a un mappage orm donc nous parlons moins d'une journée pour éventuellement changer de fournisseur). Si vous avez plus de 100 tables comme moi, c'est énorme. De plus, vous bénéficiez d'une mise en cache intégrée avec des expulsions de cache par cluster et tout est bon. SQL / Jdbc convient aux requêtes hautes performances, mais la persistance transparente est de loin supérieure pour écrire vos algorithmes et vos routines d'entrée de données. Je n'ai que 16 requêtes SQL dans tout mon système (50k + lignes de code).

J'ai étudié cela moi-même et je ne trouve pas de différence marquée entre les deux. Je pense que le grand choix est dans quelle implémentation vous utilisez. Pour moi, j'ai envisagé la plate-forme DataNucleus car il s'agit d'une implémentation indépendante du magasin de données des deux.

Quiconque dit que JDO est mort est un fudeur d'astroturf et ils le savent.

JDO est bien vivant. La spécification est toujours plus puissante, mature et avancée que le JPA beaucoup plus jeune et contraint.

Si vous souhaitez vous limiter uniquement à ce qui est disponible dans la norme JPA, vous pouvez écrire dans JPA et utiliser DataNucleus comme une implémentation de persistance haute performance et plus transparente que les autres implémentations de JPA. Bien sûr, DataNucleus implémente également le standard JDO si vous voulez la flexibilité et l'efficacité de la modélisation que JDO apporte.

J'ai utilisé Hibernate (implémentation JPA) et JPOX (implémentation JDO) dans le même projet. JPOX a bien fonctionné, mais a rencontré des bogues assez rapidement, là où certaines fonctionnalités du langage Java 5 n'étaient pas prises en charge à l'époque. Il avait des problèmes pour bien jouer avec les transactions XA. Je générais le schéma de base de données à partir des objets JDO. Il voulait se connecter à une base de données à chaque fois, ce qui est ennuyeux si votre connexion Oracle ne fonctionne pas.

Nous sommes ensuite passés à Hibernate. Nous avons joué avec l'utilisation de JPA pur pendant un certain temps, mais nous devions utiliser certaines des fonctionnalités spécifiques d'Hibernate pour faire le mappage. Exécuter le même code sur plusieurs bases de données est très simple. Hibernate semble mettre en cache les objets de manière agressive ou simplement avoir parfois un comportement de mise en cache étrange. Il existe quelques constructions DDL que Hibernate ne peut pas gérer et sont donc définies dans un fichier supplémentaire qui est exécuté pour initialiser la base de données. Lorsque j'ai rencontré un problème Hibernate, il y a souvent beaucoup de gens qui ont rencontré le même problème, ce qui facilite la recherche de solutions sur Google. Enfin, Hibernate semble être bien conçu et fiable.

Certains autres répondants ont suggéré d'utiliser simplement SQL. Le véritable cas d'utilisation du mappage relationnel d'objets est le test et le développement. Les bases de données conçues pour gérer de gros volumes de données sont généralement coûteuses et / ou difficiles à installer. Ils sont difficiles à tester. Il existe de nombreuses bases de données Java en mémoire qui peuvent être utilisées pour tester, mais qui sont généralement inutiles pour la production. Pouvoir utiliser une base de données réelle mais limitée augmentera la productivité du développement et la fiabilité du code.

J'ai créé un exemple d'application Web en mai 2012 qui utilise JDO 3.0 et DataNucleus 3.0 - regardez à quel point il est propre: https://github.com/TorbenVesterager/BadAssWebApp

D'accord, c'est peut-être un peu trop propre, car j'utilise les POJO à la fois pour la base de données et le client JSON, mais c'est amusant :)

PS: contient quelques annotations SuppressWarnings (développées dans IntelliJ 11)