Hibernate vs JPA vs JDO - Le pour et le contre de chacun?
Je connais bien le concept ORM, et j’ai même utilisé nHibernate il ya plusieurs années pour un projet .NET; Cependant, je n'ai pas suivi le sujet de l'ORM dans Java et je n'ai pas eu l'occasion d'utiliser aucun de ces outils.
Mais maintenant, j’aurai peut-être la chance de commencer à utiliser certains outils ORM pour l’une de nos applications, dans le but de nous éloigner d’une série de services Web hérités.
J'ai du mal à faire la différence entre les spécifications JPA, ce que vous obtenez avec la bibliothèque Hibernate 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?
- Que suggéreriez-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 à l'utilisation exclusive de 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 allant au-delà de celles de JPA.
OMI, je recommanderais Hibernate.
Il y a eu quelques commentaires/questions sur ce que vous devriez faire si vous besoin d'utiliser les fonctionnalités spécifiques à Hibernate. Il y a plusieurs façons de regarder cela, mais mon conseil serait:
Si vous n'êtes pas inquiet à l’idée de la connexion du 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 vous êtes inquiet par la possibilité d'un lien avec un fournisseur et que vous ne pouvez pas utiliser JPA sans recourir à des extensions spécifiques à un fournisseur, n'utilisez pas JPA. (Idem pour JDO).
En réalité, vous aurez probablement besoin de faire un compromis combien vous êtes inquiet du lien avec le fournisseur par rapport à combien vous avez besoin de ces extensions spécifiques au fournisseur.
Et il existe également d'autres facteurs, tels que le degré de connaissance des technologies respectives entre vous et votre personnel, le coût des produits en termes de licences et le récit que 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 que cela semblait si populaire, mais nous avons vite compris 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, alors vous devez écrire votre code comme celui-ci" qui a enlevé le plaisir de modéliser et de coder librement comme nous le voulons. JDO n'a jamais provoqué l'ajustement de mon code ou de mon modèle pour qu'il fonctionne correctement. Je peux simplement concevoir et coder des POJO simples comme si je n'allais les utiliser que "en mémoire", mais je peux les conserver de manière transparente.
L’autre avantage de JDO/DataNucleus par rapport à la veille prolongée réside dans le fait qu’il n’a pas toute la charge de réflexion requise au moment de l’exécution et est plus efficace en termes de mémoire car il utilise l’optimisation de l’octet de temps de construction (peut-être ajouter 1 seconde à votre temps de construction pour un projet de grande taille). que le modèle de proxy alimenté par réflexion d’hibernate au moment de l’exécution.
Une autre chose que vous pourriez trouver ennuyeuse avec Hibernate est qu’une référence à ce que vous pensez être l’objet que vous pensez est souvent un proxy pour cet objet. Sans l'avantage de l'amélioration du code d'octet, le modèle de proxy est requis pour permettre le chargement à la demande (c'est-à-dire, évitez d'extraire l'intégralité du graphique d'objet lorsque vous amenez un objet de niveau supérieur). Préparez-vous à remplacer equals et hashcode car l'objet que vous pensez référencer est souvent simplement un proxy pour cet objet.
Voici un exemple de frustration que vous aurez avec Hibernate et de JDO:
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=5
Si vous aimez utiliser des 'solutions de contournement', alors, Hibernate est fait pour vous. Si vous appréciez un développement propre, pur, orienté objet et axé sur les modèles, où vous passez tout votre temps à modéliser, concevoir et coder, sans aucune solution de rechange déplaisante, passez ensuite quelques heures à évaluer JDO/DataNucleus . Les heures investies seront remboursées mille fois.
Mise à jour de février 2017
Depuis un certain temps déjà, DataNucleus implémente le standard de persistance JPA en plus du standard de persistance JDO afin que le transfert de projets JPA existants de Hibernate vers DataNucleus soit très simple et que vous obteniez tous les avantages mentionnés plus haut 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 seulement) vs JDO (SGBDR + Pas de SQL + ODBMS + autres), DataNucleus prend en charge les deux, Hibernate est limité à JPA uniquement.
Performances des mises à jour d'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 en cascade: c’est très important lorsqu’il est nécessaire de créer le code SQL pour mettre à jour les objets modifiés dans la transaction en cours, en particulier s’il ya beaucoup d’objets. Il existe une description technique détaillée du mécanisme de vérification en profondeur d’Hibernate dans cette SO réponse: JPA avec l’insertion HIBERNATE très lente
J'ai récemment évalué et choisi un framework 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 principalement:
- 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 à une source de données non-SQL et inversement.
- pas d'objets proxy et donc moins de difficultés avec les implémentations hashcode () et equals ()
- plus de POJO et donc moins de solutions de contournement requises
- prend en charge plus de types de relation et de champ
et le soutien en faveur de JPA est principalement:
- plus populaire
- jdo est mort
- n'utilise pas l'amélioration du bytecode
Je vois beaucoup de publications pro-JPA de développeurs JPA qui n'ont clairement pas utilisé JDO/Datanucleus et qui offrent des arguments faibles pour ne pas utiliser JDO.
Je vois aussi beaucoup de publications d'utilisateurs 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 à la prise en charge des fournisseurs 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 prouve son adoption par 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 quant à la raison pour laquelle c'est mauvais.
En fait, dans un monde de plus en plus obsédé par les solutions NoSQL, JDO (et l’implémentation de datanucleus) semble bien plus sûr.
Je viens de commencer à utiliser JDO/Datanucleus et je l’ai configuré pour pouvoir basculer facilement entre db4o et mysql. Il est utile, pour un développement rapide, d’utiliser db4o et de ne pas trop s’inquiéter du schéma de base de données, puis, une fois le schéma stabilisé, de le déployer dans une base de données. Je suis également convaincu que, par la suite, je pourrai déployer tout/une partie de mon application vers GAE ou tirer parti du stockage distribué/map-réduire à la base/hadoop/cassandra sans trop de refactoring.
J'ai trouvé un peu difficile de commencer à utiliser Datanucleus - La documentation sur le site Web de Datanucleus est un peu difficile à obtenir - 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, cela dépend de ce que vous voulez. Je préférerais que le code soit plus propre, sans verrouillage du fournisseur, plus axé sur les pojos, plus vers les 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 souhaitez mener dans votre domaine, testez JDO/Datanucleus et prenez votre décision.
Que suggéreriez-vous pour un nouveau projet?
Je suggérerais ni l'un ni l'autre! Utilisez JdbcTemplate de Spring DAO avec StoredProcedure, RowMapper et RowCallbackHandler à la place.
D'après mon expérience personnelle avec Hibernate, le temps gagné au début est largement compensé par les journées interminables que vous passerez à essayer de comprendre et de résoudre les problèmes tels que le comportement inattendu de la mise à jour en cascade.
Si vous utilisez une base de données relationnelle, plus votre code y est proche, plus vous avez de contrôle. La couche DAO de Spring permet un contrôle précis de la couche de mappage, tout en éliminant le besoin de code passe-partout. En outre, il s'intègre dans la couche transaction de Spring, ce qui signifie que vous pouvez très facilement ajouter (via AOP) un comportement transactionnel compliqué sans que cela n'empiète sur votre code (bien entendu, vous l'obtenez également avec Hibernate).
JDO est mort
JDO n'est pas mort, alors veuillez vérifier 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'a eu et sa spécification ORM est toujours 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 basée sur la base de code KODO JDO datant de plus de 5 ans et extrêmement rapide/fiable). IMHO toute personne qui vous dit de contourner les spécifications vous donne de mauvais conseils. J'ai mis le temps et j'ai été récompensé. Avec JDO ou JPA, vous pouvez changer de fournisseur avec un minimum de modifications (JPA a orm mapping afin que nous parlions 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 obtenez une mise en cache intégrée avec les expulsions de cache par cluster, et c’est tout bon. SQL/Jdbc convient aux requêtes hautes performances, mais la persistance transparente est de loin supérieure pour l'écriture de vos algorithmes et de vos routines de saisie de données. J'ai seulement environ 16 requêtes SQL dans tout mon système (50k + lignes de code).
Quiconque dit que JDO est mort est un marchand de FUD astroturfeur et ils le savent.
JDO est bien vivant. La spécification est encore plus puissante, mature et avancée que la JPA beaucoup plus jeune et contrainte.
Si vous souhaitez vous limiter à ce qui est disponible dans le standard JPA, vous pouvez écrire dans JPA et utiliser DataNucleus en tant qu'implémentation de la persistance hautes performances et plus transparente que les autres implémentations de JPA. Bien entendu, DataNucleus implémente également le standard JDO si vous voulez la flexibilité et l'efficacité de la modélisation apportée par JDO.
Je me suis penché sur la question moi-même et je ne peux pas trouver une forte différence entre les deux. Je pense que le choix le plus important réside dans la mise en œuvre que vous utilisez. Pour ma part, j’ai envisagé la plate-forme DataNucleus car il s’agit d’une implémentation indépendante des deux bases de données.
J'ai utilisé Hibernate (implémentation JPA) et JPOX (implémentation JDO) dans le même projet. JPOX fonctionnait correctement, mais rencontrait assez rapidement des bugs, dans lesquels certaines fonctionnalités du langage Java 5 n'étaient pas prises en charge à ce moment-là. Il avait des problèmes pour jouer à Nice 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 gênant 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 effectuer le mappage. Exécuter le même code sur plusieurs bases de données est très facile. Hibernate semble mettre les objets en cache de manière agressive ou avoir parfois un comportement de mise en cache étrange. Il existe quelques constructions DDL que Hibernate ne peut pas gérer. Elles sont donc définies dans un fichier supplémentaire exécuté pour initialiser la base de données. Lorsque je suis tombé sur un problème d'Hibernate, beaucoup de personnes se sont heurtées au 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 test d’utilisation et le développement constituent le véritable cas d’utilisation du mappage relationnel par objet. Les bases de données conçues pour gérer de gros volumes de données sont généralement coûteuses et difficiles à installer. Ils sont difficiles à tester avec. Il existe de nombreuses bases de données en mémoire Java pouvant être utilisées pour les tests, mais qui sont généralement inutiles pour la production. Le fait de 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 c'est propre: https://github.com/TorbenVesterager/BadAssWebApp
Ok, c'est peut-être un peu trop propre, parce que 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)