novembre
2008
Un article de nicorama
En ce moment, je réécris totalement le code serveur du site Edupassion.com. Et après avoir découvert JPA il y a seulement quelques semaines, je suis maintenant sûr que la plupart des accès à la base de données d’Edupassion seront fait en JPA : plus simple à maintenir.
Cependant certaines requêtes seront très fréquemment utilisées par les utilisateurs : l’accès aux tokens d’authentification, et l’accès aux notes pour les profs et élèves. Il me parait donc logique de faire du JDBC pour optimiser ces deux-trois cas d’utilisation. Mais JDBC est-il vraiment plus rapide ? JPA vs JDBC : voici ce que j’ai trouvé sur java.net :
L’architecture est plus importante que la technologie :
[QUOTE]
The performance is completely
dependent on what you want to achieve and what actual providers you are
using. You should decide for a technology on a design or architecture
level. If you really want to decide on a performance level, you have not
understood what both are good for. Both are neither competitive, nor
comparable.
[/QUOTE]
A première vue, cela ne m’apporte rien. Un visiteur passe donc apporter la contradiction : puisque JPA est basé sur JDBC, un excellent programmeur serait capable de faire toujours mieux avec JDBC qu’avec JPA. Encore faudrait-il qu’un bon développeur existe – cela me rappelle Lex&Yacc …
[QUOTE]
With JPA vs JDBC, this is exactly the same. JDBC is the building block upon which JPA is built. JPA (as a result of standing on the
shoulders of JDBC) can never be faster than _properly tuned_ raw JDBC.
However, the JDBC code that most developers will write is going to be
slower than JPA 99% of the time…
[/QUOTE]
La réponse qui tue : JPA et JDBC n’ont pas le cache au même endroit (?!).
[QUOTE]
the JPA cache is on the client side, while the JDBC / DBMS cache is on the server side. Assuming a JDBC-based JPA implementation, you will benefit from this double buffering (if you have luck, the object is in the client side JPA cache; if you have not so good luck, it is found in the server side JDBC / DBMS cache; if you have bad luck, you must go down to the hard disc). If you do JDBC on the client side, then there is no client cache (unless your particular driver vendor implemented one directly in the client side driver). So, a JPA query will return client side cached objects, while a JDBC query must forward the server side cached data over the LAN. In sum, you have far more LAN transport with JDBC than with JPA. Unless you have client and server on the same machine, what is untypical in Client-/Server computing
[/QUOTE]
Pour ce que j’arrive à traduire et surtout comprendre, plus la quantité de données échangées entre JPA/JDBC et le serveur MySQL est importante à chaque requête, plus il est préférable de s’orienter vers JPA. Pour récupérer un token, ce serait JDBC, alors que pour récupérer un ensemble de notes dispersées entre plusieurs classes, groupes et périodes, ce serait JPA.
Ce dernier point me fait dire que si je veux faire du benchmarking, il n’aurait pas grand sens. A court terme, ma base de données est évidemment sur le même serveur, mais si j’ai un peu de succès, ca ne sera plus le cas.
L’idée d’utiliser les pojos pour alimenter ta propre couche de données est intéressante, mais bon, ça résume un peu ton objet applicatif à un DTO.
J’utilise depuis de nombreuses années maintenant JDBC et depuis 2 ans JPA and Cie.
De mon expérience, je dirais que JDBC est très bien adapté au développement de « modules de sélection » et JPA à la persistance de données structurée.
L’avantage de JDBC est que, lorsqu’on regarde une requête, on voit exactement ce qui va se passer, l’inconvénient, c’est que c’est un peu plus compliqué à mettre en oeuvre mais on ne traverse pas n couches.
L’avantage de JPA, c’est justement cette abstraction de la base de données et l’utilisation d’un graphe d’objets facilement manipulable par l’application.
Un autre avantage, non négligeable, est la possibilité de centraliser les contrôles en liant directement une méthode à un événement sur l’entity (preUpdate, prePersist, etc)
Bref, je pousse à fond vers l’utilisation du JPA, surtout dans le cadre des EJB3.
Ton commentaire est très pertinent : mon projet n’a pas besoin de JPA et les premières maquettes utilisaient JDBC. Mais justement ta dernière phrase fait la différence.
Les requêtes JPA sont plus simples, certes, mais cela impose de mieux structurer sa Bdd. Mais l’immense avantage, c’est la refactorisation ! Tu modifies un truc dans la Bdd, et hop, toutes les erreurs apparaissent dans Netbeans. Pas besoin de fouiller la trouille au ventre
De plus, en cas de pépins, les erreurs remontées par la couche JPA sont bien plus précises.
Au final, le gain en temps est colossal, alors que je ne suis qu’un pauvre débutant JPA et ORM tout court. J’ai 4 ans d’expérience en JDBC avec un beau JDBCManager fait de mes petits doigts – tout cela passe à la trappe
Reste que mon site impose un coût de connexion le plus bas possible sur certaines requêtes. Et je comprend bien sûr mieux le fonctionnement de JPA avec l’expérience JDBC.
a mon avis, si le fait de remonter des objets du sgbd ne t’apporte pas grand chose (ce qui est le cas, si tu commences par transférer leurs données vers un nouvel objet métier, sans utiliser composition/héritage), JPA ne te sert a rien. autant utiliser JDBC, ou un framework proche de JDBC (type ibatis).
Bon, en même temps, la couche jpa va te générer tout le sql, ce qui peut être particulièrement rébarbatif.
Pour moi, c’est kif-kif. J’ai mes classes métier et une base de données. Au milieu, j’ai une couche de crud (ainsi que expert et builder) qui fait relais. Avec JPA, Netbeans crée pour moi des Entity, et il y a donc un package de classes supplémentaires ainsi qu’un fichier de configuration persistence.xml.
En fait, les Entity managés par JPA ne sont PAS mes objets métiers. Ils sont certes proches puisque issus de la BDD mais je n’insère pas le moindre code dedans. Je préfère toucher à la base de donnée puis recréer les entities. En principe, c’est réversible, et c’est beaucoup plus simple à transmettre à une équipe et cela me fait l’économie d’apprentissages et donc d’erreurs couteuses.
Dans mon architecture, je peux prendre soit JPA ou JDBC en ne me souciant que des compromis simplicité/rapidité/maintenance.
Je suis du même avis que lunatix, comparer JPA et JDBC n’est pas des plus logiques car chaque spécification est adressée à un degré d’abstraction différent. JDBC est un moyen de se connecter à un SGBD, JPA un moyen de gérer la persistence de son modèle type POJO. L’un utilise l’autre et ajoute logiquement des instructions parfois couteuses, mais apporte d’autres gains.
hum, je pense que tu ne te poses pas les bonnes questions.
deja, JDBC est plus rapide qu’une implémentation JPA (oui il faut encore choisir cette implémentation, hibernate n’a pas forcement les memes perfs que toplink). Mais de toutes façons, jpa est plus haut niveau que jdbc, donc tu as une perte de performances.
Donc a mon avis, les questions a se poser sont : est-ce que une perte de (grosso modo) 1% a 10% lors des requêtes c’est important ? la plupart du temps non.
Si tu as une application sgbd intensive, (type batch par exemple), la question est pertinente par contre.
Ensuite, est-ce que le temps de développement que je vais gagner avec JPA est important (la plupart du temps… oui ;), sauf si tu geres trois tables).
et enfin, si j’ai un problème de performances, est ce que j’aurai des leviers pour le régler (oui, cache, retour a jdbc pour une requête particulière etc…)
moi je fais en général mon choix de cette facon (quoi que j’ai deja fait du batch avec hibernate et ca tourne tres bien), et j’attends le probleme de perfs avec mon netbeans en mode tunning (ou visual VM) : le plus souvent, il n’arrive pas.