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

174

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?
java hibernate orm jpa jdo mat b
la source

Réponses:

112

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.

boîte à outils
la source
8
boîte à outils, belle et courte. Un autre point à mentionner est que JPA n'empêche pas d'utiliser des fonctionnalités spécifiques à l'implémentation si nécessaire. Cela signifie que JPA vous permet d'utiliser n'importe quelle fonctionnalité Hibernate lorsque Hibernate est une implémentation.
topchef
1
Quels seraient les avantages d'utiliser JPA si j'ai besoin d'une fonctionnalité spécifique d'Hibernate?
Bruno Reis
22
Une note importante à ajouter: alors que JPA et JDO ont tous deux un excellent support pour les SGBDR, JDO est indépendant du «magasin de données» et n'est donc pas limité au monde du SGBDR. Avec la montée en puissance de NoSQL en ce moment, une personne serait sage d'envisager d'utiliser une norme de persistance qui évite de verrouiller ses applications dans le monde SQL traditionnel *. Les applications JDO peuvent facilement être déployées dans des banques de données non SGBDR. La liste complète des banques de données prises en charge peut être trouvée sur: datanucleus.org/products/accessplatform/datastores.html
Volksman
2
@Golfman pourquoi choisir en fonction de ce qui pourrait arriver? Rien ne vous empêche de faire autre chose plus tard si jamais vous avez besoin du support NoSQL ... KISS
TM.
1
@Bruno - lorsque vous utilisez des pièces non spécifiques Mise en veille prolongée de mise en veille prolongée, vous êtes utilisez JPA. De toute évidence, l'avantage de vous limiter au pur JPA est que vous pouvez passer plus facilement à une autre implémentation JPA.
Stephen C
69

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

Volksman
la source
3
Et comme nous le savons tous, l'amélioration est précisément la raison pour laquelle JDO a été si massivement adopté!
Pascal Thivent
15
Le FUD et l'astroturfing bien médiatisés exécutés par les principaux acteurs d'Hibernate dans les premiers jours par rapport à JDO sont tout simplement malhonnêtes et dégoûtants et ont sans aucun doute eu un effet sur l'adoption de JDO. De nos jours, les développeurs savent que l'amélioration du code octet n'est pas du tout un problème et l'utilisent souvent à des fins différentes autres que la persistance. La nouvelle bibliothèque d'amélioration de code d'octet ASM est si rapide que vous n'avez même pas le temps de respirer avant que cela ne soit fait.
Volksman
7
L'échec de JDO a été prédit depuis le début ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) et avant Hibernate donc vous ne pouvez pas blâmer Hibernate pour cela. Hibernate / Toplink a réussi là où les joueurs Sun et JDO (et leur OODBMS) ont échoué parce qu'ils étaient de meilleures réponses à l'époque, pas à cause du marketing et du FUD. Période. Qui se soucie si l'ASM est très rapide aujourd'hui , ce n'était pas là il y a plus de 5 ans, quand c'était nécessaire et JDO a tout simplement perdu la bataille. JDO est conceptuellement supérieur? Dommage, il a échoué à avoir une implémentation gagnante à temps (et ne reviendra pas à cause de JPA).
Pascal Thivent
2
Pour illustrer mes propos (encore un autre article qui illustre la douleur que les gens ressentaient pendant le développement ou pourquoi Hibernate a gagné la bataille): mail-archive.com/[email protected]/… . Il me semble évident que la réflexion / cglib était une réponse pratique aux problèmes des gens (et les gens ne se soucient pas de savoir si une API est conceptuellement supérieure si c'est difficile à utiliser) et je ne vois pas d'acteurs clés d'Hibernate ici, juste des utilisateurs . Donc à la fin je me demande qui diffuse du FUD en fait ...
Pascal Thivent
7
Eh bien, ce n'est certainement pas comme au bon vieux temps où il y aurait eu au moins 17 messages pro Hibernate FUD différents (mais venant seulement de 3 adresses IP différentes. Faites les maths people =)).
Volksman
54

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.

À M
la source
9
En fait, comme je l'ai dit, je donnais juste mes impressions de ce que j'avais découvert en essayant de trouver une solution. Oui, je suis un débutant en Java, pourquoi cela devrait-il être si relavent? Vous, d'autre part, avez posté un certain nombre de fois en déclarant votre opinion que JDO est mort sans offrir aucun fait ou preuve pour le corroborer et ne pas reconnaître les domaines techniques où JDO est clairement supérieur. Vous avez évidemment quelque chose de personnel contre JDO / Datanucleus et vous utilisez ces threads comme un moyen de perpétuer votre position anti-JDO.
Tom
4
Pascal - vous vous disputez dans un coin ici. Je pense que vous manquez le point de la section Publicité de la FAQ. Le PO a demandé des avis sur 2 technologies. Il invite ceux qui soutiennent les deux camps à se manifester et à présenter leurs critiques / recommandations constructives. Pour Andy / Datanucleus et d'autres utilisateurs de JDO, mettre en évidence les aspects positifs de JDO et se défendre contre les critiques n'est pas plus publicitaire que quelqu'un d'autre recommandant d'utiliser la mise en veille prolongée.
Tom
5
Vous feriez bien de vous référer à la section de la FAQ qui dit «Soyez gentil» car vos messages sur ce sujet ont été accusateurs, conflictuels ou tout simplement impolis. Votre premier était un commentaire sarcastique sur l'amélioration. Seconde; une diatribe sur les difficultés des premières implémentations et n'est plus d'actualité. Troisièmement, des moqueries et des insultes enfantines envers ceux qui préfèrent ne pas utiliser le SGBDR. Quatrièmement, les moqueries sarcastiques de quelqu'un qui a des points de vue différents sur vous. Le cinquième était une attaque; m'appelant un perroquet. Considérez-vous cela «être gentil»?
Tom
3
Si vous avez eu une expérience horrible avec JDO, expliquez ce qui était horrible, reconnaissez que c'était avec une version antérieure et que les choses ont peut-être été améliorées depuis. Vous devez également reconnaître que les autres peuvent avoir des besoins différents de vous. Ce n'est pas parce que vous êtes «satisfait» de JPA et que vous souhaitez utiliser un SGBDR que les autres le sont. Peut-être que dans votre hâte d'augmenter votre réputation, vous avez perdu de vue ce que cette réputation est là à récompenser? ps. En tant que développeur, vous devriez vraiment vous intéresser au bien-être de tels projets, car c'est ce qui stimule l'innovation et réduit le blocage des fournisseurs.
Tom
6
Ce sera ma réponse finale :) .. 1. S'il ne fallait pas se demander pourquoi la soulever? 2. Je n'ai jamais remis en question votre honnêteté, j'ai dit que vous n'étiez pas gentil avec les autres affiches et que vous vous étiez contredit. 3. personne ne vous a suggéré de résumer plus de 8 ans - mais étayez vos déclarations avec des faits et des exemples plutôt que des déclarations subjectives susceptibles d'offenser. 5. Où est l'attitude «hibernate / jpa / jboss is evil» sur ce message? Je ne le vois pas. Je ne vois que vos commentaires anti-JDO.
Tom
40

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).

oxbow_lakes
la source
4
il s'agit clairement d'un choix de mappage anti-objet-relationnel (ORM) motivé par le grand nombre d'utilisateurs et de codes accumulés depuis l'époque ODBC (début des années 90) (lecture héritée). Il n'y a aucune raison de ne pas utiliser JDBC (avec ou sans Spring) à moins que vous ne choisissiez de passer à autre chose et d'utiliser le framework ORM. Pensez à ces personnes qui ont un jour décidé d'abandonner FORTRAN pour utiliser C ou Pascal.
topchef
23
@grigory - Je parle avec beaucoup d'expérience de perdre des jours à essayer de comprendre les problèmes d'Hibernate, tels que les mises à jour / suppressions en cascade, les structures de requêtes ridiculement inefficaces, etc. En tant que tel, il est peu probable que la connaissance d'Hibernate à elle seule aboutisse à un bon produit final. D'après mon expérience, au cours du cycle de vie du projet, Hibernate (et ORM par extension) coûte plus de temps qu'il n'en économise
oxbow_lakes
8
désolé que vous ayez eu une si mauvaise expérience avec Hibernate. Je viens moi-même d'une école de base de données lourde / SQL / procédure stockée / JDBC. Je ne peux pas dire que je suis converti - chaque technologie ci-dessus a encore sa place. Mais pour une application Java à 3 niveaux à usage général (quelle que soit la taille), le premier choix est une technologie ORM - de préférence JPA 2. D'autres doivent être pris en compte en fonction de ces facteurs, code hérité, intégration, expertise, exigences lourdes en lots, temps réel les performances, etc. qui peuvent orienter (ou non) l'approche vers une pile technologique de base de données différente.
topchef
3
Je suis complètement en désaccord avec la définition "quick-win" ci-dessus - il suffit de saisir Hibernate in Action ( stackoverflow.com/questions/96729/… ) (et c'est JPA 1, avec JPA 2 ça ne fait que mieux) pour comprendre pleinement la puissance et la couverture de cette technologie a.
topchef
7
J'ai fait un peu de recherche et Spring ne recommande plus Spring DAO ( static.springsource.org/spring/docs/3.0.x/… ): "Le style d'intégration recommandé est de coder les DAO par rapport aux API Hibernate, JPA et JDO. l'ancien style d'utilisation des modèles DAO de Spring n'est plus recommandé; "... Est-ce ce que vous recommandiez? Si oui, pourquoi ne le recommandent-ils pas?
User1
23

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

DonnéesNucleus
la source
12
Les gens l'utilisent très certainement, comme en témoignent les nombreux utilisateurs de DataNucleus, sans parler de Xcalia, Kodo. Vous manquez l'idée de base que JDO et JPA ne remplissent pas le même marché. JPA est exclusivement un SGBDR. JDO est indépendant de la banque de données et est utilisé pour le SGBDR, mais aussi LDAP, XML, Excel, OODBM, etc.
DataNucleus
3
J'aime le facteur non-SGBDR, en particulier avec l'augmentation de la popularité des solutions non-SGBDR, c'est un gros problème. Cela signifie que si JPA n'évolue pas assez rapidement, la disponibilité d'une alternative «plus ouverte» et plus flexible (JDO) signifie que la popularité de JPA baissera, par nécessité. Peu importe les arguments techniques selon lesquels JDO est plus complet, supérieur, mature ou autre, ce ne sera pas une question de préférence . Il est logique que les fournisseurs de SGBDR se comportent de manière suspecte - l'époque de la domination du marché des SGBDR touche peut-être à sa fin.
Manius
Nous utilisons toujours JDO / DataNucleus en 2019! Il est maintenant à la version 5.x et bat toujours Hibernate pour la productivité des développeurs et les performances d'exécution. Récemment, j'ai dû faire des consultations sur une grande application Web utilisant Hibernate et je me suis souvenu de la douleur que j'ai subie lorsque j'étais un utilisateur et un promoteur actif de HIbernate il y a de nombreuses années.Un chef d'équipe ne m'a pas cru quand je lui ai dit que son champ BLOB était toujours recherché avec impatience même s'il était marqué comme paresseux. L'absence totale de connaissances «sous le capot» par un expert auto-proclamé «expérimenté» d'Hibernate était malheureusement dérangeante mais attendue.
Volksman
10

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).


la source
8

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.

tapi
la source
6
+1 pour DataNucleus, pas pour la réponse.
WolfmanDragon
8

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.

Volksman
la source
1
Ou vous utilisez une autre implémentation (fine) avec une communauté beaucoup plus grande et par conséquent plus réactive. Oui, certaines personnes s'en soucient aussi.
Pascal Thivent
1
Et vous parlez de FUD> :) Drôle.
Pascal Thivent
2
Votre commentaire semble présumer que je n'ai pas utilisé à la fois Hibernate et JDO.
Volksman
2
Ce fil semble avoir énormément de références de la part de quelques personnes à la qualité de DataNucleus. Veuillez ne pas utiliser cet endroit comme plate-forme publicitaire.
TM.
3
Rien d'étonnant de la part de Golfman qui colle encore et encore le même truc marketing désespéré dans chaque thread impliquant JPA ou DataNucleus (qu'il utilise depuis 1996 , avant même qu'il n'existe !).
Pascal Thivent
2

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.

Sean McCauliff
la source
1
Pour autant que je sache, JPOX a changé de nom en DataNucleus (et a eu des versions depuis lors).
Donal Fellows
2
Je pense que vous constaterez en fait que DataNucleus a beaucoup moins de bogues ouverts que les autres logiciels auxquels vous faites référence. Je pense que vous constaterez également que le développement de DataNucleus réduit le nombre de bogues à un rythme plus rapide que cet autre logiciel.
DataNucleus
1

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)

Torben Vesterager
la source