sans titre 1
Lorsqu’on veut mettre au point
une grille, dans un programme, on utilise soit une grille du marché, soit on
hérite de la grille de Microsoft.
Les grilles du marché sont des
boîtes préprogrammées à tout faire, mais tout est rédigé façon non démontable,
elles sont plein de macro-fonction dont on ne peut pas se départir pour
s’accoler à tel ou tel principe, et si le besoin informatique du projet est
pesant, le nombre est important de ces macro-fonctions qui répondent peu au
besoin ou qui s’éloignent complètement du besoin, ou qui sont d’une ergonomie
affreuse qu’on ne peut pas retoucher. Exemple, encore maintenant, dans la grille
la plus connue, les filtres en entête, si on choisit une liste, n’affichent que
les 50 premiers éléments sans barre de défilement. Autre exemple que je connais,
quand ça coche tout seul plusieurs milliers de lignes, c’est lent. Ces grilles
sont faites pour vendre leur macro-fonctions, leur côté visuel, leur côté
attrape l’attention première et primaire.
Pour un petit besoin, mieux vaut
prendre la grille de base, pour un moyen besoin, elles peuvent répondre à la
demande d’un développement court, pour un grand besoin, il faut prendre le
principe d’un développeur pompier de Microsoft que je connais qui dit : « Se
dire que le développement avec une grille ne marche jamais bien ».
En ce qui concerne le besoin
informatique pesant, on peut conjuguer grand besoin et petit budget en utilisant
une grille du marché, donc qui ne répondra jamais bien au besoin, mais on peut
aussi avoir le budget pour développer quelque chose de très personnel, très
personnalisé, très personnalisable. On hérite alors d’une des grilles de
Microsoft, la DataGridView en WinForms ou la DataGrid en WPF.
Pour les mobiles, pour les
Stores, il est pratiquement impossible de faire de vraies grilles. Pour
Internet, il est pratiquement impossible de faire de vraies grilles de saisie,
ainsi qu’une fenêtre pratique sur un grand nombre de données, des arbres et des
grilles à la fois…
Mais une grande erreur de
repartir de l’héritage d’une grille Microsoft, est que pour chaque projet on
hérite une nouvelle fois de la grille.
Pourtant, au bout d’un moment,
on se rend compte que ce sont toujours un peu les mêmes fonctions qu’on
redéveloppe dans chaque projet. Et les projets sont devenus irréconciliables,
les fonctions ayant été ajustées au cas par cas sans une pensée pour la
réutilisation. Pourtant, on en aura besoin, de la réutilisation. On voudra
profiter de telle barre de filtres, de telle ouverture de sélection directement
dans la grille, de tel outil de regroupement, de tel outil d’exportation en
règle, de telle personnalisation… On voudra intégrer deux projets en un, puis
deux… Si le code est écrit avec le minimum de méthodologie, cela équivaut à
imbriquer trente grandes fonctions dans trente grandes fonctions, chaque ligne
de code d’un côté venant potentiellement influencer de l’autre côté, chaque cas
où on teste tel cas multi-conditionnel risquant de devoir être complété sans
oubli, sans erreur, sans passage nouveau inopportun.
Donc, l’héritage est un bon
principe, par exemple en vue de se faire une grille d’entreprise, mais il faudra
qu’elle soit complètement générique, complètement indépendante de toute
déclaration spécifique quelconque, et qu’elle contienne suffisamment de
fonctions de base pour répondre aux cas majeurs.
Je vous invite de ce pas à
consulter mon autre article sur un tel héritage que j’ai développé de manière
inter-entreprises. C’est une grille qui, on peut le dire, répond à la totalité
des cas grâce à un principe modulaire, héritable, décorable, avec les bonnes
fonctions en virtuel choisies. A l’occasion, je peux vous faire des
démonstrations, ou tenter une participation ensemble. Elle a une couche de
personnalisation telle qu’elle pourrait être commercialisée sans la partie pour
le développeur.
On découvre alors, en
développant une telle grille, que certaines bonnes méthodes sont à remettre en
question : En aval, pour un meilleur développement dans le cas de l’utilisation
d’une grille, comme le développement de la couche entités de base de données, on
comprend alors le problème du designer-first, le problème de la non indépendance
des tables de clé externe de ce modèle, le problème de la répétition de la
définition de champs dans plusieurs couches, particulièrement les couches MVVM,
l’impossibilité chez Microsoft de pouvoir définir des requêtes sur des champs
définis par l’utilisateur, donc que le passage par requête reste la meilleure
formule pour notre cas…
Les deux grilles Microsoft sont
limitées en nombre de fonctions, mais ont été ouvertes au développement aéré
dans tous les sens, et proprement structuré. Ce qui n’est pas beaucoup le cas
des grilles tiers, qui veulent surtout avoir un grand nombre de fonctions de
base, à leur manière. Mais les grilles Microsoft ont encore de gros défauts,
qu’un héritage permet de travailler avec quelques petits bidouillages de
contournement. C’est aussi là qu’il vaut mieux avoir dans un outil réutilisé et
donc sur lesquels ont aura planché pour stabiliser que de faire ce genre de
forçage d’incapacité (car ce ne sont pas des bugs) dans des héritages multiples,
fragiles si on ne les travaille pas, fragile s’ils peuvent subir les aléas des
cas nouveaux et particuliers.
On découvrira au fur et à mesure
des développements que certaines bonnes méthodes d’éditeurs de logiciels nous
reviennent : comme le fait de faire une couche moteur indépendante de l’accès à
la base, faire une couche d’un moteur d’accès à la base (un genre d’ensemble de
builders, quoi), (suivie d’un héritage pour chaque logiciel de base de données),
une couche très auto-générée de mapping avec la base (qui sera la couche Model),
la nécessité d’écrire son propre générateur (pourquoi pas paramétrable), une
couche par type d’interface (WPF, WinForms, et pourquoi pas à partir de là, la
principale étant l’une de ces deux-là, développer de petits moteurs
supplémentaires qui mettent à profit les autres développements pour avoir un
rendu minimum sur un site…) Et une couche qui gère une personnalisation. (Tout
ceci n’étant pas les couches ni ViewModel, ni View, qui sont dans l’ordre la
couches métier orientée modules et la couche interface orientée modules).
On découvrira de nouvelles
notions : Tel que l’intérêt de mettre un maximum de la couche métier dans des
héritages des tables concernées du mappage de la base de données (purement,
unitairement, plutôt que les dupliquer dans la couche ViewModel), donc de mettre
ce code dans la couche Model, ce qui permet de définir une fabrique de tables
externes qui ne seront que des héritages normés de l’objet Table abstrait qu’on
aura créé dans la couche de base, intéressant de les utiliser tels quels pour
les valeurs suggérées d’un champ. Le principe de décrire le code là où il est
logique de le mettre (par exemple si une décoration est reproduite dans
l’ensemble d’une entité, décrire ce décorateur dans cette entité ou un héritage
de base), donc qu’il n’est pas vilain d’avoir au minimum une possibilité de
décrire quelques éléments graphiques de façon abstraite dans ces entités…
Même Microsoft, finalement, est
toujours dans le doute que ça ne marche jamais bien en ayant réécrit un nombre
incroyable de fois sa couche abstraite de moteur d’accès aux données et les
outils correspondants de mappage (ODBC, DAO, ADO, ADODB, ADO.NET, LinqToSql,
Entities, WCF, Entities code-first). Tout cela n’est qu’insistance pour que les
développeurs redéveloppent dans chacune de ces écritures successives, mais suite
à de véritables échecs de conception sur lesquels je reviens dans un autre
article (futur). Bien des entreprises ont carrément redéfinis le leur (de couche
de moteur d’accès aux données, ainsi que l’outil de mappage correspondant) et
n’en bougent plus, car le cœur de Visual Studio.Net reste, indéfiniment, de 2002
jusqu’à maintenant. Sauf peut-être les concepteurs d’interface qui s’accumulent
aussi.
Frédéric Decréquy, version 1 du
22 juillet 2017.