Dans la série ne critiquons pas gratuitement, voici quelques points rapides en complément (réponse?) à cet article sur les pilotes (drivers) JDBC de http://developpeur.journaldunet.com/.
– Type 1: Bon pour les maquettes tout au plus. Pas ou peu maintenu et effectivement trop de couches à traverser (et donc de bug à contourner diront certains).
– Type 2: Nécessite l’installation de code natif (librairie partagée .dll ou .so) qui est probablement la bonne compréhension de “ne peuvent être utilisés que dans les environnements disposant d’une API propriétaire”. C’est une contrainte faible pour les serveurs d’application J2EE, énorme pour les applets ou les applications Java (ceci dit, Applet + JDBC = architecture douteuse).
– Type 3: Très rarement utilisé à ma connaissance. C’est probablement lié à l’avènement des serveurs d’application J2EE qui font toute l’optimisation prévue initialement par ces serveurs de connexions JDBC.
– Type 4: Réécriture en Java de la partie native des drivers de type 2. Initialement les performance étaient mauvaises. Elles sont aujourd’hui (et depuis quelques années) devenues excellentes. Disons qu’il s’agit plus d’un pilote qui implémente le protocole natif que des “portages en Java des API propiétaires”.
Dans une architecture “classique” N-niveaux à base de serveurs d’application J2EE, les pilotes JDBC de type 2 mettent plus de charge sur la base de données alors que les pilotes de type 4 concentre la charge sur la couche serveur d’application. Le choix est souvent lié à ce point et à ce qu’un éditeur de serveur d’application recommande et certifie.
Enfin, pour des utilisations avancées de JDBC (avec Hibernate, JDBC Rowsets, etc…) une implémentation de JDBC 3.0 est souvent nécessaire et même là, tous les pilotes ne se valent pas…
Pour aller un peu plus loin une fois que l’on a choisi son type de driver, il faut choisir la mani�re dont on va se servir de JDBC. L’API JDBC “crue” n’�tant pas tr�s digeste je recommande de jeter un oeil au package jdbc du framework spring:
DAO and JDBC support with Spring
Data Access using JDBC
Certes, mais ce terrain est glissant ;-) JDO, EJB, Spring, POJO, Hibernate, …
Le sujet du choix d’un pilote reste orthogonal au choix du framework de persistance (ou presque)
Tout � fait, chacune de ces solutions a ses avantages et ses d�fauts, et il n’est pas facile de faire le bon choix. En tout cas rester avec l’API jdbc nue ou �crire un nouveau framework par dessus JDBC n’est pas une bonne id�e.
Ma pr�f�rence va � la partie JDBC de Spring (juste la partie jdbc inutile d’utiliser tout Spring si ce n’est pas n�cessaire) car c’est du JDBC sans les lourdeurs de JDBC (gestion des exceptions, m�canisme d’�x�cution des requetes ou des proc�dures stock�es…).
Si le besoin d’une solution de mapping O/R se fait sentir, Hibernate est actuellement la meilleure solution.
Pour la partie persistance les EJB entity sont morts (� moins qu’ils ne rennaissent de leur cendre en EJB 3, mais ce ne sera pas tout de suite).
JDO contient de bonne chose mais les produits manquent de maturit�s et tardent � s’imposer. De plus JDO s’est fait griller la politesse par Hibernate qui est en train de devenir un standard de fait.
Maintenant il est vrai que toutes ces solutions reposent au final sur JDBC et le choix du driver JDBC peut avoir un impact tr�s important sur les performances.
Off-topic, mais le site qui s’affiche quand je clique que l’URL d’Aur�lien est … aussi off-topic !!!
Gwenael
PS : pourtant, j’utilise FireFox !?
Je ne sais pas ce que tu entends pas off-topic.
La bonne URL est la suivante: http://aurel.is.free.fr/blog
-Alexis
Je voulais dire “hors sujet”.
Quand je clique sur l’URL de Aur�lien (qui �tait mal form�, soit) j’arrive sur … http://www.microsoft.com ??!??
Gwenael