Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Aussi comme TopLink, JPOX, maintenant connus comme DataNucleus, utilise un agent JVM pour faire le runtime weaving.Envoyé par djo.mos
java -javaagent:datanucleus-enhancer.jar ....
http://www.datanucleus.org/products/...r.html#runtime
----
Erik Bengtson
DataNucleus (JPOX)
Bonjour à tous,
personnellement je suis entrain de développer une application en utilisant JPA.
Et je suis persuadé qu'avec JPA ,les problème du provider ( Hibernate, Toplink,..) ne se pose plus. en changeant seulement 2 lignes , le tour est joué.
On peut migrer rapidement de telle façon qu'on peut éviter les problèmes des uns et profiter des biens des autres.
Par exemple pour migrer de toplink à hibernate en utilisant le fichier de configuration de spring (spring-config.xml) :
il suffit de :
choisir l'une de ces 2 lignes :
et l'une de ces deux ligne :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
J'espère que ça peut aider.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Salut,
que pensez-vous de cette remarque:
Q: What will happen to other data persistence APIs now that the Java Persistence API is available?
A: The Java Persistence API is now the standard API for persistence and object/relational mapping for the Java EE platform. Earlier APIs of course will not go away, but we expect that they will become less interesting once this new standard API is available.
from Java Persistence API FAQ
Traduction:
Q: Que va t'il arriver aux autres frameworks de persistance maintenat que JPA est disponible ?
R: JPA est maitnenant le le framework ORM standard pour JavaEE. Les frameworks qui le précèdent ne vont pas disparaitre bien sûr, mais on prévoit qu'ils seront moins intéressants une fois ce nouvel framework (JPA) serait disponible.
Et personellement, ce genre de citations ne me fait ni chaud ni froid ... plus clairement, ça ne veut strictement rien dire
Je rappèle juste que je suis pro JPA, mais ce choix n'a pas été dicté par ce genre de remarques (==hype) péchées sur le net, mais par ses qualités intrinsèques.
N'oublions pas qu'EJB 2 a été présenté à son époque comme étant la solution standard et intéressante pour les application Java EE
Ce que tu dis crée l'occasion de poser une question :
Est-ce que tu veux dire que lors de la phase de réalisation tu n'as pas sous les yeux une modélisation de ton domaine (en termes de données, c'est à dire un MCD ou un MPD) à laquelle tu colles avec tes annotations ?
Si oui, pourquoi ne pas utiliser une base de données objet ?
Dans ce cas pas de problématique d'ORM à prendre en compte.
Et d'une manière général, en sortant un peu du sujet, pourquoi les bases de données objet ne se généralisent-elles pas plus ? (Je précise que je n'en ai pas utilisé encore)
Ca vient quand même du site de sun. Java Persistence API FAQdjo.mos:
... péchées sur le net ...
Alors ya un avenir pour hibernate et les autres ou pas?
Bonjour,
Bien sûr qu'il ont encore de l'avenir !
Par exemple, JPA est tout simplement non envisageable pour tout projet non Java 5+, et Hibernate (ou autres) devient dès lors une option intéressante.
De plus, JPA et Hibernate (et quelques autres) qui relient fortement sur le proxying ne sont pas adaptés dans le cas d'applications distribuées où l'on sérialise les PAOs pour leur transfert via réseau.
Dans des cas pareils, rien ne vaut un ORM (ou même pas) simple et sans proxying, comme Spring JDBC ou iBatis par exemple.
Y'au aussi des cas où l'on est guidée par une base existante, avec un schéma tellement complexe (ou crade) qu'un ORM n'y arrive tout simplement pas, où l'on revient vers le bon vieux JDBC.
Bref, je dirais que les divers ORMs sont compartimentés, avec chaque bloc couvrant des cas particuliers d'utilisations.
Leçon du jour: Il n'y a pas de 'Silver Bullet': faut essayer de tester plusieurs ORMs et choisir celui qui nous semble le plus confortable mais surtout le plus adpaté au besoins.
donc voilà, finalement j'ai essayé hibernate et hibernate/JPA et voici mon retour d'expérience:
je commence par la conclusion : je préfère utiliser hibernate dans mon code pour profiter de l'approche objet lors des requetes (Criteria et autre)
j'ai commencé par utiliser hibernate/JPA parce que les annotations ca faisait plus sexy que d'avoir des fichiers de mapping. Ceci dit, les annotations obligent à se trainer les libs correspondantes. Dans une appli distribuée comme la mienne, il était hors de question de filer 5Mo de libs pour que le client [java de mon application distribuée] puisse utiliser mes 2ko de POJO.
à part cela, les deux sont bien (la courbe d'apprentissage est peut etre un peu moins longue pour hibernate/JPA, mais il y a plus d'exemples pour hibernate de base)
Débugger du code est deux fois plus dur que d'en écrire.
Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.
j'ai utilisé à quelques reprises db4o, une bd objet
et j'ai beaucoup apprécié la facilité de mise en oeuvre
quand on a pas 17 millions de donnée.... c'est une bd rapide, simple et efficace
Salut,
bon je suis encore Junior et je ne développe plus en J2EE pour l'instant mais je conseillerais aussi Hibernate.
Celui qui s'interesse à Hibernate n'est pas sans savoir que son créateur(Gavin King) fut impliqué dans le comité de décision de JPA (sous spécification des ejb, si je ne me trompe pas). Voilà pourquoi Hibernate est aussi flexible avec JPA.
ATTENTION cependant car Hibernate fournit lui aussi ses propres annotations(je parle de Hibernate 3, ici)
Donc, je donnerai le conseil suivant: si tu adoptes Hibernate, essaye d'utiliser au maximum les annotations de JPA et non celles d'hibernate, sauf lorsque tu n'as pas le choix(A la limite marque les avec un todo, ou un fixme pour les retrouver plus facilement plus tard). Ca t'évitera bien des soucis si ton appli doit changer d'application server...
Voilà ma maigre contribution, en espérant ne pas avoir dit trop de conneries
Salut,
Comme alternative à JDBC, j'ai essayé iBatis et je le trouve pas mal car il est simple à mettre en oeuvre surtout si on l'associe avec Spring.
Sinon, dommage qu'il ne supporte pas les generics de java5.
Retour d'expérience pour la persistance des données :
JDBC :
Approche bas niveau, on contrôle ce qu'on fait.
Une fois des classes génériques écrites, on peut simplifier le code à écrire. (Voir peut être utilisé Spring JDBC mais je n'ai pas essayé.)
Le gros avantage pour moi est de pouvoir via des interfaces, éviter des copies/recopies d'objets : On lit le ResultSet et on remplit directement notre objet de données qui peut implémenter les interfaces nécessaires par les objets de la vue.
L'inconvénient, c'est l'écriture des requêtes SQL.
JDO :
J'ai essayé JPOX (implémentation de JDO). Ce qui me séduit, c'est de pouvoir faire des requêtes "Java Like" plutôt que "SQL Lite".
Autre avantage, JDO s'adresse à plusieurs solutions de persistances et pas seulement des SGBDR comme JPA.
JPA :
J'ai essayé JPA avec l'implémentation d'Hibernate en suivant le cours de Serge Tahé sur ce site. D'après lui, le passage d'une implémentation à l'autre n'est pas aussi triviale dans certains cas.
Ce qui m'a séduit, c'est d'annoter directement mes objets métiers et de générer la base de données dynamiquement en cours de développement.
Pour moi, c'est la POO (diagramme UML des classes ...) qui pilote le tout et plus du tout Merise ... Le diagramme des classes remplace avantageusement le MCD. Alors pourquoi ne pas utiliser une bdd objet ? J'aimerai bien mais il faut reconnaitre (à mon grand regret) que les éditeurs de SGBDR ont "verrouillé" ce marché. Les SGBDR ont tellement de recul (rassurant en entreprise), de fiabilité, de sécurité, de performance que j'ai bien peur que les SGBDO ne pénètrent le marché des entreprises de si tôt.
Les petites difficultés rencontrées :
En utilisant Spring, les transactions sont super faciles à gérées mais il ne faut pas oublier de mettre un listener de spring dans son web.xml sous peine d'avoir des sessions fermées prématurément.
A moins que quelle chose m'ait échappé, j'ai pas mal galéré avec les relations many to many qui doivent être manipulables des 2 côtés de la relation. Le passage par un objet intermédiaire explicite est incontournable et pour supprimer un enregistrement de la table de jointure, il faut déréférencer des deux côtés préalablement !!! c'est un peu lourd à mon goût.
Conclusion :
Entre JPA (Hibernate) et JDO (JPOX), mon cœur balance.
Les deux sont des API standards, peuvent utiliser des fichiers XML ou des annotations JAVA.
Leur avantage premier selon moi est "l'indépendance des SGBDR" :
Tant qu'on n'écrit pas de requêtes SQL par nous même (les deux sont débrayable et le permettent), on peut changer de SGBDR. Passer d'un Oracle à un MySQL à un SQLServer ...
Car il faut bien reconnaître que certaines choses ne sont pas dans les standards SQL (pas encore) comme de prendre les enregistrements 30-50 d'une table pour afficher une liste paginée.
Un petit mot concernant iBatis. Si je ne me trompe pas, ces avantages sont :
1/ d'externaliser ses requêtes SQL
2/ de remplir automatiquement ses objets métiers à partir de requêtes SQL.
C'est donc un intermédiaire intéressant entre JDBC et les JPA/JDO.
Sa limite pour moi est qu'il n'a pas le principal avantage "d'indépendance des SGBDR" cité plus haut. Ce qui n'est pas génant en soi si on ne souhaite pas changer de SGBDR et/ou tant qu'on écrit du SQL standard.
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
J'aime bien iBatis, pour sa simplicité de mise en oeuvre (tu définis simplement les requêtes SQL qui doivent permettre de sélectionner/insérer/modifier tes objets ou tes listes d'objets) à condition de toucher en SQL.
Sinon, Hibernate, j'y ai goûté, c'est bien aussi, surtout si on a envie de se plonger dans le HQL, qui est puissant, bien que pas trop intuitif.
J'en profite pour poser une question en rapport avec le sujet : y a-t-il une solution plus légère que les autres, adaptée en particulier à une utilisation dans une application desktop, par dessus une base JavaDB ou HSQLDB embarquée ? Parce que Hibernate, ça me parait pesant, pour ça, quand même.
iBatis pourrait convenir, je pense, mais s'il existe des solutions alternatives, je suis preneur.
Pour une liste complète des bibliothèques de persistance open-source pour Java : http://java-source.net/open-source/persistence
Et donc, j'ai la réponse à ma question précédente : Ammentos et Persist sont taillés pour les applications desktop.
Sérieux, faux qu'ils arrêtent
qu'ils arretent quoi ? d'en faire parce que y'en a trop ? ^^
Débugger du code est deux fois plus dur que d'en écrire.
Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.
C'est un domaine où les spécifications officielles se sont empilées : Entity Beans, JDO, JPA, sans parler des systèmes non-officiels comme Hibernate ou iBatis (qui ont rejoint les standards par la suite), parce que les premières spécs n'étaient pas vraiment à la hauteur. Il y a vraiment à boire et à manger, dans cette liste.
si tu utilises ses "mini bd" essaye db40, bd object
+1, c'est très pratique et ça nécessite 0 administration (ou presque) ni de mappping.
Faut seulement faire très attention à la licence de DB4O qui est GNU quand il s'agit de l'utiliser dans un produit commercial (sans vouloir toutefois lancer un troll à ce sujet).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager