JDO vs JPA pour Java sur Google App Engine

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

Merci.

JPA est la norme de Sun pour la persistance, JDO est IMHO en train de mourir (en fait, il est mort mais toujours en mouvement). En d’autres termes, JPA semble être un meilleur investissement sur le long terme. Donc je suppose que je choisirais JPA si les deux étaient nouveaux pour moi.

Le groupe GAE / J Google a plusieurs articles à ce sujet. Je ferais une recherche là-bas et regarderais les opinions 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

Juste vu cette comparaison entre JPA et JDO par DataNucleus eux-mêmes: – http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Une révélation.

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

Les personnes qui prétendent que JDO est mort ne sont pas sans mérite. Voici ce que j’ai lu dans le livre Pro EJB 3 Java Persistence API: «Peu de temps après, Sun a annoncé que JDO serait réduit en mode maintenance et que l’API Java Persistence serait à la fois compatible avec JDO et les autres fournisseurs de persistance. norme à l’avenir “. L’auteur Mike Keith est le leader de la co-spécification sur EJB3. Bien sûr, il est un grand partisan de JPA, mais je doute qu’il soit assez partial pour mentir.

Il est vrai que lorsque le livre a été publié, la plupart des principaux fournisseurs étaient unis par JPA plutôt que par JDO, même si JDO possède des fonctionnalités techniques plus avancées que JPA. Ce n’est pas surprenant, car les grands acteurs du monde de l’EE tels qu’IBM / Oracle sont également de gros fournisseurs de SGBDR. Plus de clients utilisent RDMBS que les non-RDMBS dans leurs projets. JDO mourait jusqu’à ce que GAE lui donne un gros coup de pouce. Cela a du sens, car le magasin de données GAE n’est pas une firebase database relationnelle. Certaines fonctionnalités JPA ne fonctionnent pas avec bigtable, telles que les requêtes d’agrégation, les requêtes de jointure, les relations multi-propriétaires. BTW, GAE prend en charge JDO 2.3 tout en ne supportant que JPA 1.0. Je recommanderai JDO si GAE est votre plateforme cloud cible.

Pour mémoire, il s’agit de Google App Engine (GAE), nous jouons donc avec les règles de Google et non avec les règles Oracle / Sun.

En vertu de cela, JPA ne convient pas à GAE, il est instable et il ne fonctionne pas comme prévu. Ni Google n’est disposé à le supporter, mais le ssortingct minimum.

Et pour l’autre partie, JDO est assez stable dans GAE et il est (dans certains cas) bien documenté par Google.

Cependant, Google n’en recommande aucun.

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

L’API de bas niveau donnera les meilleures performances et GAE, ce sont les performances.

http://gaejava.appspot.com/

Par exemple, ajoutez 10 entité

Python: 68ms

JDO: 378ms

Java natif: 30 ms

En 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 familiers avec les modèles de données autres que relationnels, par exemple Big Table. Je suis sûr que les développeurs d’Hibernate étaient là, il aurait dit: “toutes nos hypothèses lors de la construction de nos bibliothèques principales sont étroitement liées au modèle relationnel, l’hibernation n’est pas optimisée pour GAE”.

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

Du sharepoint vue de la programmation, l’utilisation des API JDO est une bien meilleure option, car vous compromettez conceptuellement beaucoup moins. Vous pouvez, en théorie, basculer vers n’importe quel modèle de données de votre choix, à condition que le fournisseur que vous utilisez prenne en charge la firebase database sous-jacente. (En pratique, vous atteignez rarement un tel niveau de transparence, car vous vous retrouverez à définir vos clés principales sur l’object de GAE et vous vous lierez à un fournisseur de firebase database spécifique, par exemple Google). il sera quand même plus facile de migrer.

Troisièmement, vous pouvez utiliser Hibernate, Eclipse Link et même spring avec GAE. Google semble avoir fait de gros efforts pour vous permettre d’utiliser les frameworks sur lesquels vous avez l’habitude de construire vos applications. Mais ce que les gens réalisent lorsqu’ils construisent leurs applications GAE comme s’ils fonctionnaient sur un SGBDR, c’est qu’ils sont lents. Le spring sur GAE est lent. Vous pouvez google Google IO vidéos sur ce sujet pour voir que c’est vrai.

En outre, respecter les normes est une bonne chose à faire, en principe, j’applaudis. D’autre part, JPA faisant partie de la stack Java EE, les gens perdent parfois la notion d’options. Réalisez, si vous voulez, que Java Server Faces fait également partie de la stack Java EE. Et c’est une solution incroyablement ordonnée pour le développement de l’interface graphique Web. Mais au final, pourquoi les gens, les plus intelligents, si je puis dire, s’écartent de cette norme et utilisent plutôt GWT?

Dans tout cela, je dois affirmer qu’il ya une chose très importante pour JPA. C’est Guice et son support pratique pour JPA. Il semblerait que Google ne soit pas aussi intelligent que d’habitude à ce stade et qu’il soit satisfait, pour le moment, de ne pas supporter JDO. Je pense toujours qu’ils peuvent se le permettre, et finalement 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 à prendre en main et vous aurez une nouvelle compétence à votre scope!

Ce que je trouve terrible à propos de l’utilisation de JDO au moment de la rédaction de cet article, c’est que le seul fournisseur d’implémentation est Datanucleus et que les inconvénients sont le manque de concurrence, ce qui entraîne de nombreux problèmes comme:

  1. Une documentation pas très détaillée sur certains aspects comme les extensions
  2. Vous obtenez généralement des réponses sarcastiques des auteurs comme (Avez-vous vérifié les journaux? Peut-être il y a une raison de les avoir) et des réponses ennuyeuses comme ça
  3. Vous n’obtenez pas de réponse à votre question dans un laps de temps utile, parfois si vous obtenez une réponse en moins de 7 jours, vous devriez vous considérer chanceux, même ici sur StackOverflow

J’espère toujours que quelqu’un commencera à appliquer lui-même la spécification JDO , peut-être alors qu’il offrira quelque chose de plus et espérera peut-être plus d’ attention à la communauté sans se soucier d’être payé pour le support, sans dire que les auteurs de Datanucleus soutien commercial, mais je dis juste.

Datanucleus auteurs de Datanucleus n’ont aucune obligation envers Datanucleus lui-même ni sa communauté. Ils peuvent abandonner tout le projet à tout moment et personne ne peut les juger, c’est leur effort et leur propre propriété. Mais vous devez savoir dans quoi vous vous engagez. Vous voyez, quand l’un de nous, développeurs, cherche un framework à utiliser, vous ne pouvez pas punir ou commander l’auteur du framework, 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’autre part, JDO lui-même des complications comme le cycle de vie des objects et des choses peu intuitives et courantes (je pense).

Edit: Maintenant, je sais que JPA applique le mécanisme de cycle de vie des objects, il semble donc inévitable de traiter les états de cycle de vie d’entités persistants si vous souhaitez utiliser une API ORM standard ( JPA ou JDO )

Ce que j’aime le plus chez JDO c’est la possibilité de travailler avec N’IMPORTE QUEL système de gestion de firebase database.

GAE / J devrait append MYSQL avant la fin de l’année.

JPA est la voie à suivre car elle semble être une API standardisée et a récemment pris son envol dans EJB3.0. JDO semble avoir perdu de la vitesse.

Ni!

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

Objectify est une API d’access aux données Java spécialement conçue pour le magasin de données Google App Engine. Il occupe un “terrain d’entente”; plus facile à utiliser et plus transparent que JDO ou JPA, mais nettement plus pratique que l’API de bas niveau. Objectify est conçu pour rendre les novices immédiatement productifs tout en exposant toute la puissance du magasin de données GAE.

Objectify vous permet de conserver, d’extraire, de supprimer et d’interroger vos propres objects saisis.

 @Entity class Car { @Id Ssortingng vin; // Can be Long, long, or Ssortingng Ssortingng color; } ofy().save().entity(new Car("123123", "red")).now(); Car c = ofy().load().type(Car.class).id("123123").now(); ofy().delete().entity(c);