JDO vs JPA pour Java sur Google App Engine
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 me suggérer à ce sujet? Les deux sont nouveaux pour moi et je dois les apprendre. Je me concentrerai donc sur l'un après vos réponses.
Merci.
JPA est la norme de Sun pour la persistance, JDO est à mon humble avis (en fait, il est mort mais toujours en mouvement). En d'autres termes, JPA semble être un meilleur investissement à long terme. Donc je suppose que je choisirais JPA si les deux étaient nouveaux pour moi.
Le groupe Google GAE/J a plusieurs articles à ce sujet. Je ferais une recherche là-bas et regarderais les opinions des gens. Vous obtiendrez 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: - 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 gens qui prétendent que JDO est mort n'est 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 au mode de maintenance des spécifications et que le Java = L'API de persistance s'inspirerait à la fois de JDO et des autres fournisseurs de persistance et deviendrait la seule norme prise en charge à 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 il est assez biaisé 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. Ce n'est pas surprenant car les grands acteurs du monde de l'EE tels qu'IBM/Oracle sont également de grands fournisseurs de SGBDR. Plus de clients utilisent RDMBS que non-RDMBS dans leurs projets. JDO était en train de mourir 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 base de données relationnelle. Certaines fonctionnalités JPA ne fonctionnent pas avec bigtable telles que les requêtes d'agrégation, les requêtes Join, les relations plusieurs-à-plusieurs possédées. BTW, GAE prend en charge JDO 2.3 alors qu'il ne prend en charge que JPA 1.0. Je recommanderai JDO si GAE est votre plateforme cloud cible.
Dans la course entre JDO vs JPA, je ne peux qu'être d'accord avec les affiches du datanucleus.
Tout d'abord, et surtout, les affiches de datanucleus savent ce qu'elles font. Ils développent après tout une bibliothèque persistante et connaissent bien les modèles de données autres que relationnels, par ex. Grande table. Je suis sûr que si un développeur pour hibernate était là, il aurait dit: "toutes nos hypothèses lors de la construction de nos bibliothèques de base sont étroitement couplées au modèle relationnel, hibernate n'est pas optimisé pour GAE".
Deuxièmement, JPA est incontestablement en usage plus répandu, faisant 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 lire à ce sujet, correspond à un niveau d'abstraction plus élevé que JPA JPA est étroitement couplé au modèle de données RDBMS.
Du point de vue de la programmation, l'utilisation des API JDO est une bien meilleure option, car vous compromettez beaucoup moins conceptuellement. Vous pouvez basculer, théoriquement, 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 vous retrouverez à définir vos clés primaires sur l'objet de GAE et vous vous lierez à un fournisseur de base de données 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 un gros effort pour vous permettre d'utiliser les frameworks sur lesquels vous êtes habitué à construire vos applications. Mais ce que les gens réalisent lorsqu'ils construisent leurs applications GAE comme s'ils fonctionnaient sur RDBMS, c'est qu'ils sont lents. Le printemps sur GAE est LENT. Vous pouvez google Google IO vidéos sur ce sujet pour voir que c'est vrai.
En outre, le respect des normes est une bonne chose à faire, j'applaudis en principe. D'un autre côté, JPA faisant partie de la pile Java EE), les gens perdent parfois leur notion d'options. Réalisez, si vous voulez, que Java = Server Faces fait également partie de la pile Java EE. Et c'est une solution incroyablement bien rangée pour le développement de l'interface graphique Web. Mais au final, pourquoi les gens, les gens les plus intelligents si je peux le dire) , s'écarter de cette norme et utiliser GWT à la place?
Dans tout cela, je dois dire qu'il y a une chose très importante pour JPA. C'est Guice et son support pratique pour JPA. Il semble que google n'était pas aussi intelligent que d'habitude à ce stade et se contente, pour l'instant, de ne pas prendre en charge JDO. Je pense toujours qu'ils peuvent se le permettre, et éventuellement Guice engloutira également JDO, ... ou peut-être pas.
Allez JDO. Même si vous n'y avez pas d'expérience, ce n'est pas difficile à acquérir et vous aurez une nouvelle compétence à votre actif!
Ce que je trouve terrible à propos de l'utilisation de JDO au moment de la rédaction, c'est que le seul fournisseur d'implémentation est Datanucleus et les inconvénients sont le manque de concurrence qui conduit à de nombreux problèmes comme:
- Une documentation peu détaillée sur certains aspects comme
extensions - Vous obtenez généralement des réponses sarcastiques des auteurs comme (Avez-vous vérifié les journaux? Peut-être y a-t-il une raison pour les avoir) et des réponses ennuyeuses comme ça
- 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 à implémenter la spécification JDO lui-même, peut-être qu'il offrira quelque chose de plus et, espérons-le, plus gratuit attention à la communauté et ne se souciant pas toujours d'être payé pour le support, sans dire que les auteurs de Datanucleus ne se soucient que du support commercial, mais je dis juste.
Personnellement, je considère que les auteurs de Datanucleus n'ont aucune obligation envers Datanucleus ni envers sa communauté. Ils peuvent abandonner tout le projet à tout moment et personne ne peut les juger pour cela, c'est leur effort et leur propre propriété. Mais vous devez savoir dans quoi vous vous embarquez. 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 que votre travail soit fait! Si vous aviez le temps d'écrire ce cadre, pourquoi en chercheriez-vous un en premier lieu?!
D'un autre côté, JDO lui-même a quelques complications comme le cycle de vie des objets et d'autres choses qui ne sont pas très intuitives et courantes (je pense).
Edit: Maintenant, je sais aussi que JPA applique le mécanisme du cycle de vie de l'objet, il semble donc inévitable de traiter les états de cycle de vie d'entités persistantes si vous souhaitez utiliser une API ORM standard (c'est-à-dire JPA ou JDO)
Ce que j'aime le plus dans JDO, c'est la possibilité de travailler avec N'IMPORTE QUEL système de gestion de base de données sans effort considérable.
GAE/J devrait ajouter MYSQL avant la fin de l'année.
Ni!
Utilisez Objectify, car c'est moins cher (utilisez moins de ressources) et plus rapide. Pour info: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify est un Java API d'accès aux données spécialement conçu pour la banque 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 le API de bas niveau Objectify est conçu pour rendre les novices immédiatement productifs tout en exposant également toute la puissance de la banque de données GAE.
Objectify vous permet de conserver, de récupérer, de supprimer et d'interroger vos propres objets saisis.
@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);
JPA est la voie à suivre car il semble être poussé comme une API standardisée et a récemment pris de l'ampleur dans EJB3.0. JDO semble avoir perdu le Steam.