blog.bressure.net

Le monde J2EE est souvent jugé complexe mais cette complexité apparente n’est que la réponse nécessaire aux problématiques réelles des SI. De son côté WebDev propose une solution aguicheuse pour le développement mais tient-il la comparaison ?

Dans un billet précédents je déclarais que la cible de WebDev n’était pas la même que J2EE. WebDev semble s’adresser à une population d’informatiien et surtout de non informaticien pour développer des applications de gestion CRAD (portemanteau de CDRUD et de RAD). Après quelques semaines passé à manipuler WebDev voici mes conclusions.

Du point de vue du développeur (rôle développeur en J2EE), le langage WLangage n’est pas Objet. On est trop souvent amené à appeler des fonctions qui ne sont pas des méthodes d’objet ni de classe. Ce sont bel et bien des fonctions. Le paradigme de programmation du WLangage (langage propriétaire utilisé par WebDev) est donc bancal. Se voulant objet, puisque l’on peu faire des objets, il n’impose malheusement pas ce modèle. Si le lecteur doute de la pertinence de l’objet en matière de génie logiciel, je ne peux que lui conseiller de mettre à jour ses connaissances.

Certaines fonctions sont elles-mêmes bancales dans leur signature. Ainsi le fonction qui test si une chaine commence par une autre est bien nommée ChaîneCommencePar mais ne retourne pas un booléen mais un entier…. Donc le développeur passe d’un niveau d’abstration fonctionnel avec des fonction dont le nom est significatif à un autre, celui d’un test en langage C….

Une fois l’application développé vient le temps du déploiement. Comme on veut comparer WebDev et J2EE, nous sommes dans le contexte d’un SI d’entreprise voire d’un éditeur, avec des environnements de test, de preé-production et de production. Là où J2EE permet de découpler le code de l’application des paramètres de l’environnement comme les sources de données qui sont du ressort de l’administrateur (rôle déployeur en J2EE). Ainsi le mème livrable pourra être déployé en test ou en production, le code étant totalement agnostique de l’environnement, Quelle solution propose WebDev ?

La notion de connexion nommée est interne à l’IDE qui confond allègrement nom de connexion et nom de variable dans le but de simplification à outrance. Ainsi une connexion définie dans l’IDE est référencé par son nom en tant que variable et nom pas en temps que chaine. Les connexions semblent devoir être définies lors du développement. WebDev inscite donc à repasser par l’AGL et déclarer les connexions spécifiques à l’environnement cibles puis recompiler et redéployer l’application. Une fois dployée l’application est alors scotchée à sa source de donnée…. WebDev ne fait donc pas de découplage entre application et source de données!

Néanmoins on peut par programmation construire une connexion et l’affecter aux tables (appelées Fichiers) du programme. Cette méthode est celle préconisée par le support pour rendre l’application multi-cible. Finalement c’est un développeur si il a un minimum de compétence en génie logiciel, de prévoir ce qui est du ressort de la technique et donc contraire à la cible première de WebDev. Par ailleur le support propose une solution hasardeuse de détecter l’environnement en fonction de l’IP du serveur… sous-entendant que le code doit tester si il est en test ou en prod. WebDev est donc a proscrire pour les éditeurs qui devraient connaitre l’IP de tous les serveurs de ses clients!

Une première solution pourtant existe et aurait dû être proposée par le support. Lors du déploiement l’AGL propose d’inclure des fichiers supplémentaires. Il suffit d’ajouter un fichier de type INI qui contient la définition de la connexion pour l’instance en train d’être déployée. Par programmation, l’application lors de son initialisation va lire ce fichier et créer la connexion puis surcharger la connexion de l’analyse. Cependant, cette méthode oblige toute modification des sources de données de se faire soit en redéployant soit en allant modifier le fichier INI sur le serveur. On peut aller plus loin en incluant un fichier (Table) d’initialisation qui contiendrait les valeurs de connexions aux tables métiers et un module d’administration pour modifier la table de paramétrage… Dommage que WebDev ne propose pas cela dans son modèle, ce qui lui aurait permis de soutenir la comparaison avec J2EE.

Derrière un marketing singulier dans le monde des éditeurs, WebDev est un AGL qui ressemble plus à une boîte à outils pour assembler rapidement des applications focalisées sur l’apparence. Certes, on développe vite des IHM mais le modèle applicatif n’est pas celui attendu par des SI d’entrepise et encore moins celui de professionnelles de l’informatique comme les éditeurs. Définitivement, a moins de s’adjoindre les services d’un spécialiste en architecture ou génie logiciel, l’utilisation de WebDev n’est pas adaptée à un SI d’entreprise avec des contraintes autres que celles du médecin qui veut développer un IHM sur son fichier de patients.