Styles

jeudi 17 septembre 2009

Inadaptation d’impédance objet-relationel : plus qu'une inadaptation, une incompréhension

Cet été 2009, Thomas Kyte, expert développement sous Oracle bien connu, s’est largement étendu sur son site AskTom de questions/réponses, sur l’inadaptation d’impédance objet-relationel (object-relational impedance mismatch). Sur un ton direct et tranchant, il nous délivre son point de vue sur la place des « applications » notamment Java EE et de leurs rôles dans la gestion des données. Il fini par énoncer cette règle à suivre absolument :
Ne laissez aucun développeur qui code en Java, Visual Basic, C et autres langages de ce genre, écrire du code contenant SELECT, INSERT, UPDATE, DELETE ou MERGE dedans. Donnez leur accès à une série de procédures stockées qui retournent les données dont ils ont besoin, ou qui traitent les transactions nécessaires au système lui-même.
Assez radical il est vrai, Tom ne considère les applications au dessus des bases de données que comme de simples interfaces homme-machine (en gros, de simples JSP ou pages PHP suffisent pour faire interagir un client avec le serveur de données). Pour lui, autant ne pas donner aux applications un accès direct aux tables, au modèle de données parce que les applications vont et viennent rapidement mais les données,… les données vivent pour toujours ! :

… je peux à la rigueur mettre tout le SQL dans la base de données au lieu que dans du XML, ce n’est ni un gros problème pour moi ni un gros gain d’un côté technique…

Cela m’indique (« ni un gros gain ») que vous n’avez pas fait de bases de données depuis longtemps. Votre application – la chose pour laquelle vous vous concentrez aujourd’hui en 2009 – elle n’existera plus vers 2013. Mais la donnée, elle, sera toujours là. Et si vous avez caché tout ce qui concerne les données dans votre application obsolète écrite dans un langage mort, avec des frameworks que personne ne considère plus utiliser (rappelez-vous, c’est 2013, plus 2009 maintenant) – vous nous forcerez à l’en arracher entièrement et à le recommencer.
Le reste des réponses de Tom est du même acabit. C’est comme si le monde était séparé en deux : les programmeurs sur framework et les programmeurs sur base de données. En entreprise, la plupart des applications existent pour gérer l’information, gérer des données. Les traitements associés sont rarement compliqués et ne font jamais appel à des experts en algorithmie.

Dans quel cas a-t-on réellement besoin d'une machine à gaz ORM ? Quels sont les clients qui analysent leur métier en termes d’objets ? Parmi ces clients, quels sont ceux qui comprennent toutes les notions, aspects et pièges de l’orienté-objet ?

J’ai rencontré il y a quelques temps, en 2007, un client pour lequel j’ai du réaliser un audit de sécurité sur son application Java. Quand arrive le moment de lire le code source de l’application (qui date de 2002), un effroi (les englishs diraient, « WTF » à ce moment là) m’envahi quand je réalisai que ce qui avait été codé était un véritable serveur d’application complet codé à la main, spécifiquement pour ce client !

Ah, les développeurs s’en étaient donné à cœur joie pour créer cette majestueuse machine à gaz, capable de gérer des composants aussi complexes que des EJB 1.0, inmaintenables et inmaintenu actuellement, puisque plus personne n’a plus le temps de se pencher sur son fonctionnement, les développeurs initiaux ayant changés au moins 3 fois de société de service entre temps. Et puis, ce n’est pas un simple serveur d’application minimaliste qui a été codé, mais un énorme tas de technologies du moment comme par exemple, CORBA et IIOP qui étaient en vogue au moment du développement de cette application.

J’aurais pu me dire que tout cela était nécessaire à l’époque, notamment pour supporter une charge importante, des changements de configuration fréquents, un clustering, de la réplication de sessions, de l’intégration d’autres systèmes… Que nenni ! Toute cette machinerie ne sert qu’à gérer une cinquantaine de tables dans une base oracle et ne fait qu’1 ou 2 appels vers des WebServices, 1 intégration avec un LDAP… et puis c’est tout !


Autant dire que tout ce code Java ne sert strictement à rien ! Et coûte énormément à maintenir… Une simple application générée par « Oracle Application Express » aurait suffit. Je vous passe les autres détails de l’architecture de cette application, qui révèle bien que le client n’a pas du tout investi sur sa base de données mais uniquement sur des programmes en Java… Pour quelle raison ? J’ai beau tourner maintes et maintes fois la question dans ma tête je ne vois pas de raison logique à tout ça. C’est certainement une question de mode du moment.

Aucun commentaire: