Drivers JDBC



JDBC

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…

Author: alexismp

Google Developer Relations in Paris.

6 thoughts on “Drivers JDBC”

  2. 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)

  3. 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.

Comments are closed.