Discussion :

[galie]

Bonjour,

je viens d’intégrer une société qui utilise du Delphi 7 couplé à Oracle pour son application de gestion.
Leur particularité est de ne pas utiliser de classe mappée à la base de donnée, Delphi n'a aucune connaissance de la base, la couche métier est intégrée dans Oracle par du Pl-sql.
Je ne sais pas si je m'exprime bien mais pour donner une exemple, il n'y a pas de classe Personne dans Delphi mais une procédure qui va appeler directement une fonction Oracle qui manipulera la table Personne.

Cette construction me dérange et je souhaiterais avoir votre avis sur le sujet.
J'ai déjà signalé cette particularité au responsable informatique en lui signifiant qu'avec cette construction ils ne pourrait jamais travailler avec une base de donnée externe sur laquelle ils n'auraient pas la main mais la possibilité de pouvoir changer facilement IDE lui semble plus importante.

Je ne suis pas une spécialiste en architecture n tiers c'est pourquoi si vous pouviez me donner votre avis, cette architecture est elle bonne ou mes craintes sont elles fondées ? je manque d'argument

Merci pour votre aide

Galie

[Luckyluke34]

Bienvenue dans le monde du legacy. C'était une approche courante il y a plus d'une dizaine d'années mais elle est un peu tombée en désuétude. Je ne vais pas refaire le match, une recherche Google te permettra de déterrer les flamewars qui ont eu lieu entre pro et anti procédures stockées.

Pour moi le problème principal du code métier dans des SP n'est pas tant de ne pas pouvoir changer de SGBD mais qu'on se prive de toutes les facilités fournies par un IDE moderne en termes de navigation dans les sources, refactoring, outils de productivité, tests unitaires, debugging avancé, génération de code...

Fixer le code business dans la base de données pour avoir le loisir de changer le langage au-dessus était peut-être une approche valide il y a 10 ans, mais le sens de l'histoire ne lui a pas donné raison. Aujourd'hui, la partie programmation des SGBD évolue peu et elles sont attaquées de toutes parts par des approches plus légères (NoSQL...) qui se contentent d'être des stockages persistants très efficaces sans chercher à faire le café et le ménage. D'autre part, il y a un boom de la diversité des langages, des approches de programmation, des environnements de développement, de leur intégration avec les environnements de build, d'ALM, etc. alors que les langages genre PL/SQL ou T-SQL sont restés essentiellement procéduraux avec un outillage autour qui a peu évolué. Aujourd'hui, un développeur qui ne fait que du PL/SQL aura toutes les chances d'atterrir sur un projet legacy et quasiment aucune de travailler sur un produit greenfield ou récent.

Une transition progressive vers une architecture plus moderne est possible, mais il est souvent difficile de convaincre des décideurs qui voient une application qui marche et ne mesurent pas la nécessité de la faire évoluer. Jouer sur des métriques de temps de résolution de bugs et de réalisation d'évolution peut être une approche, mais si tout le système d'information est conçu de cette manière, le manque de point de comparaison va empêcher de débloquer les choses. Malheureusement, il faut souvent arriver à des extrémités comme un énorme gaspillage d'argent et de temps sur une application en fin de vie pour que tout le monde comprenne qu'il aurait fallu réagir avant...