JDO vs JPA pour Java sur Google App Engine

https://stackoverflow.com/questions/1418219

07-07-2019
|

Question

Je souhaite développer mon projet sur Google App Engine avec Struts2. Pour la base de données, j'ai deux options JPA et JDO. Voulez-vous les gars s'il vous plaît me suggérer à ce sujet? Les deux sont nouveaux pour moi et j'ai besoin de les apprendre. Je vais donc me concentrer sur l'une après vos réponses.

Merci.

La solution

JPA est la norme de Sun en matière de persistance, JDO est en train de mourir (à mon humble avis, il est mort mais reste en mouvement). En d'autres termes, l'APP semble être un meilleur investissement sur le long terme. Je suppose donc que je choisirais JPA si les deux étaient nouveaux pour moi.

Autres conseils

Le groupe google GAE / J a publié plusieurs articles à ce sujet. Je ferais une recherche là-bas et regarderais l'opinion des gens. Vous recevrez un message très différent des opinions exprimées ci-dessus. Concentrez-vous également sur le fait que BigTable n'est pas un SGBDR. Utilisez le bon outil pour le travail

Je viens de voir cette comparaison entre JPA et JDO par DataNucleus eux-mêmes: - Une révélation.

Je suis un utilisateur heureux de JDO. Continuez votre bon travail les gars.

Les gens qui prétendent que JDO est mort n’est pas sans mérite. Voici ce que j'ai lu dans le livre API de persistance Java EJB 3 Pro: "Peu de temps après, Sun a annoncé que JDO serait réduit au mode de maintenance de la spécification et que l'API de persistance Java tirerait à la fois de JDO et des autres fournisseurs de persistance et deviendrait le fournisseur unique. norme prise en charge pour aller de l'avant. " L'auteur Mike Keith est le leader de la co-spécification sur EJB3. Bien sûr, il est un grand partisan de l'APP, mais je doute qu'il soit assez partial pour mentir.

Il est vrai que lorsque le livre a été publié, la plupart des grands fournisseurs étaient unis derrière JPA plutôt que JDO, même si JDO possède des fonctionnalités techniques plus avancées que JPA. Cela n’est pas surprenant, car les grands acteurs du secteur EE tels que IBM / Oracle sont également de grands fournisseurs de SGBDR. Plus de clients utilisent RDMBS que de non-RDMBS dans leurs projets. JDO était en train de mourir jusqu'à ce que GAE lui donne un coup de pouce. Cela a du sens car le magasin de données GAE n’est pas une base de données relationnelle. Certaines fonctionnalités de JPA ne fonctionnent pas avec bigtable, telles que les requêtes d'agrégation, les requêtes de jointure, les relations propriétaire à plusieurs. BTW, GAE prend en charge JDO 2.3, mais uniquement JPA 1.0. Je recommanderai JDO si GAE est votre plate-forme cloud cible.

Pour mémoire, il s'agit de Google App Engine (GAE). Nous ne jouons donc pas avec les règles de Google ni avec les règles Oracle / Sun.

En dessous, JPA ne convient pas à GAE, il est instable et ne fonctionne pas comme prévu. Ni Google ne veut le supporter, mais le strict minimum.

En outre, JDO est assez stable dans GAE et il est (dans une certaine mesure) bien documenté par Google.

Cependant, Google ne recommande aucun d'entre eux.

http://code.google.com/appengine/docs/ java / datastore / overview.html

L'API de bas niveau donnera les meilleures performances et GAE est tout au sujet de la performance.

http://gaejava.appspot.com/

Par exemple, ajoutez 10 entités

Python: 68 ms

JDO: 378ms

Java Native: 30 ms

Dans la course entre JDO et JPA, je ne peux qu’être d’accord avec les affiches datanucleus.

Tout d’abord, et surtout, les affiches de datanucleus savent ce qu’elles font. Après tout, ils développent une bibliothèque persistante et sont familiarisés avec les modèles de données autres que le modèle relationnel, par exemple. Grande table. Je suis sûr que les développeurs d’Hibernate étaient présents, aurait-il déclaré: "Toutes nos hypothèses lors de la construction de nos bibliothèques principales sont étroitement liées au modèle relationnel, hibernate n’est pas optimisé pour GAE".

Deuxièmement, JPA est incontestablement plus utilisé, faire partie de la pile officielle Java EE aide un peu, mais cela ne signifie pas nécessairement que c'est mieux. En fait, JDO, si vous lisez à ce sujet, correspond à un niveau d'abstraction plus élevé que JPA. JPA est étroitement lié au modèle de données du SGBDR.

Du point de vue de la programmation, l’utilisation des API JDO est une bien meilleure option, car vous compromettez beaucoup moins sur le plan conceptuel. Vous pouvez théoriquement basculer vers n'importe quel modèle de données de votre choix, à condition que le fournisseur que vous utilisez prenne en charge la base de données sous-jacente. (En pratique, vous atteignez rarement un niveau de transparence aussi élevé, car vous devrez définir vos clés primaires sur l’objet de GAE et vous vous attacherez à un fournisseur de base de données spécifique, par exemple Google). il sera toujours plus facile de migrer cependant.

Troisièmement, vous pouvez utiliser Hibernate, Eclipse Link et même printemps avec GAE. Google semble avoir fait de gros efforts pour vous permettre d'utiliser les frameworks sur lesquels vous construisez vos applications. Mais ce que les gens réalisent lorsqu'ils construisent leurs applications GAE comme si elles fonctionnaient sur un SGBDR, c'est qu'elles sont lentes. Le printemps sur GAE est lent. Vous pouvez rechercher des vidéos Google IO sur ce sujet dans Google pour voir que cela est vrai.

En outre, le respect des normes est une bonne chose sensée à faire, en principe je me félicite. En revanche, JPA faisant partie de la pile Java EE, les utilisateurs perdent parfois leur notion des options. Si vous le souhaitez, sachez que Java Server Faces fait également partie de la pile Java EE. Et c'est une solution incroyablement soignée pour le développement d'interface graphique Web. Mais finalement, pourquoi les gens, les plus intelligents, si je puis dire, s’écartent-ils de cette norme et utilisent-ils plutôt GWT?

Dans tout cela, je dois dire qu’il ya une chose très importante pour JPA. C’est Guice et son support pratique pour JPA. On dirait que Google n'a pas été aussi intelligent que d'habitude sur ce point et qu'il est content, pour le moment, de ne pas supporter JDO. Je pense toujours qu'ils peuvent se le permettre et, éventuellement, Guice engloutira aussi JDO, ... ou peut-être pas.

Allez JDO. Même si vous n’avez pas d’expérience, ce n’est pas difficile à maîtriser et vous aurez une nouvelle compétence à votre actif!

Ce que je pense est terrible d'utiliser JDO au moment d'écrire ces lignes, c'est que le seul fournisseur d'implémentation est Datanucleus et que l'inconvénient est le manque de concurrence qui conduit à de nombreux problèmes tels que:

Une documentation peu détaillée sur certains aspects tels que extensions
Vous obtenez généralement des réponses sarcastiques de la part des auteurs, telles que (Avez-vous vérifié les journaux? Peut-être y a-t-il une raison de les avoir) et des réponses agaçantes comme celle-ci
Vous n'obtenez pas de réponse rapide à votre question. Parfois, si vous obtenez une réponse en moins de 7 jours, vous devez vous considérer chanceux, même ici sur StackOverflow .

J'espère toujours que quelqu'un commencera à implémenter la spécification JDO eux-mêmes, peut-être qu'ils offriront quelque chose de plus et, espérons-le, plus d'attention gratuite à la communauté et ne vous inquiétez pas toujours d'être payé pour une assistance, ne dites pas que les auteurs de Datanucleus s'intéressent uniquement à l'assistance technique, mais je dis simplement.

Je considère personnellement que les auteurs de Datanucleus n’ont aucune obligation de Datanucleus ni de sa communauté. Ils peuvent abandonner le projet dans son intégralité à tout moment et personne ne peut en juger, ce sont leurs efforts et leur propriété. Mais vous devriez savoir dans quoi vous vous engagez. Vous voyez, quand l'un de nous développeurs recherche un framework à utiliser, vous ne pouvez pas punir ou commander son auteur, mais d'un autre côté, vous avez besoin de votre travail! Si vous aviez le temps d’écrire ce cadre, pourquoi en chercheriez-vous un en premier lieu?!

D'un autre côté, JDO en lui-même présente certaines complications telles que le cycle de vie des objets et d'autres choses qui ne sont pas très intuitives et communes (je pense).

Éditer: Je sais maintenant que JPA applique le mécanisme de cycle de vie d'un objet. Il semble donc qu'il soit inévitable de traiter les états de cycle de vie d'entités persistantes si vous souhaitez utiliser une API ORM standard (< code> JPA ou JDO )

Ce que j'aime le plus à propos de JDO est la possibilité de travailler avec TOUT système de gestion de base de données sans effort considérable.

GAE / J doit ajouter MYSQL avant la fin de l'année.

JPA est la voie à suivre car il semble être poussé comme une API normalisée et a récemment pris son essor dans EJB3.0 .. JDO semble avoir perdu le rythme.

Ni l'un ni l'autre!

Utilisez Objectify, car c’est moins cher (moins de ressources) et plus rapide. Pour info: http://paulonjava.blogspot.mx/2010/12/tuning -google-appengine.html

Objectify est une API d’accès aux données Java spécialement conçue pour le Banque de données Google App Engine. Il occupe un "terrain d'entente"; plus facile à utiliser et plus transparent que JDO ou JPA, mais beaucoup plus plus pratique que l’API de bas niveau. Objectify est conçu pour faire novices immédiatement productifs mais exposent aussi toute la puissance de la Magasin de données GAE.

Objectify vous permet de conserver, de récupérer, de supprimer et d'interroger vos propres objets typés.

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow