CollectionEngine pour la
bibliothèque d’accès aux données pour développement.
FdReports pour le
progiciel de constitution wysiwyg de rapports dynamiques et de grilles de
saisie.
·
Le sujet
Les énergies se dispersent à réinventer plusieurs fois
la même chose. Les socles se croisent mais ne se regroupent pas. Il est souvent
vain de vouloir mettre en place un socle générique gérant tous les
fonctionnements, le nombre très important de cas particuliers et porteurs de
socle empêche de trop nombreuses machine-arrière.
En effet, depuis les 40 dernières années, 50% de
l’informatique est l’informatique de gestion et 50% de l’informatique de
gestion est composé des grilles de saisie et d’édition.
On se perd dans des fonctions inconnues si on ne va
pas à fond dans le modèle où on insère son propre code à un endroit précis. Si
l’on code la logique métier dans le langage de la grille, il devient alors
vraiment impossible de remplacer une grille par une autre. D’où l’intérêt
d’utiliser les méthodes de séparation par couches indépendantes, tel MVVM.
·
Résumé
CollectionEngine est un outil décisionnel dynamique,
paramétrable et personnalisable, entièrement écrit par moi, mais dans
différentes entreprises, que je distribue gratuitement et que je développe chez
moi aussi. Il existe aussi sous la forme d’un explorateur de base de données
qui n’exige ni développement, ni installation.
·
Description
Une bibliothèque de fonctions de grilles de saisie et
d'édition qui pourrait servir à tout le monde et qui contient toutes les
fonctions qui peuvent être intéressantes pour faire un Framework fixe, qui n'a
pas besoin d'être remodelé, remodulé en permanence, pour pouvoir réellement
tout faire dans le domaine, très rapide mais pas toujours facile à mettre en
place, toujours avec succès, facile à remodeler, bibliothèque entièrement
indépendante du fonctionnel, avec un très faible taux de vices cachés.
Les 3 points fondamentaux techniques de la
bibliothèque qui lui apportent toute son énergie est que :
·
Le
DataColumn travaille avec un DataColumnFiltre qui gère de façon générique les
cas communs de filtrage sur une colonne, particulièrement une valeur exclusive
et un ensemble de valeurs exclusives, ces deux types de filtrages permettant de
nombreuses déductions automatiques au sein du logiciel.
·
Le
deuxième fondamental est que sur un DataColumn des DataTable, des propriétés
permettent d’affecter un DataTable fournissant les valeurs suggérées. Lors du
mappage automatique assisté par du manuel dans une autre couche, on pourra
servir dans l’événement ce DataTable de valeurs suggérées, dont la clé sera la
source par défaut de la valeur.
·
Le
troisième est la possibilité d’intervenir facilement pour faire de la
retouche à la volée, toujours structurée et naturelle aux différentes
étapes d’obtention de la valeur, de manipulation, de validation, de
présentation abstraite.
Les 4 points fondamentaux architecturaux de la
bibliothèque lui apportent sa sécurité, sa rapidité de développement, le peu de
complexité du code, hormis à l’exécution, quelle que soit la complexité
réelle :
·
Direction
par les modèles. La direction par source unique, les Modèles, leur parent générique et
leurs enfants, assure quand à elle la sécurité des données. Le parent générique
apporte un cadre chaud, généreux, actif et plein de fonctionnalités génériques
à chaque structure qui s’y base, lui offrant ses moteurs, par exemple un moteur
de règles. En même temps, on ne s’éloigne pas trop du mode MVVM.
·
Direction
par sujet naturel. Appelé aussi principe de séparation des préoccupations. Lorsqu’on croise
les fers, il faut que les socles parlent le même langage. C’est à Microsoft de
le concevoir, mais je peux lui apporter une expérience unique, ayant poussé ma
carrière de développeur informatique vers une étude permanente de ce genre de
cas légitime.
·
Suivi
du principe de définitions uniques. Appelé aussi principe Dry. Il consiste à n’avoir
qu’une fois chaque définition de sujet, faisant autorité, sans avoir à répéter
le code et ses modifications, ses divergences le temps passant, l’impossibilité
de fusionner le temps passant. Le code développeur final est alors flexible,
petit, facile à interpréter, sans ambigüité, facile à maintenir, réutilisable,
et sans source d’erreur.
·
Direction
par le code d’abord. Les designers et les assistants ne font pas autorité. Ils ne
permettent pas de tout décrire. Le code si. Mais les mélanges entre les deux ne
sont pas bons. Il faut que l’un dirige, contienne tout, contienne les retouches
et pas l’autre, donc l’autre contient des éléments figés. Tout doit pouvoir
être décrit, donc c’est le code qui dirige.
On pourrait imaginer que ces informations suffisent,
mais si on ne profite pas de mes cas résolus, tel que des méthodes de
conversion automatique de la clé de valeur suggérée en valeur de cellule, ou
l’expérience d’avoir mis au point un événement qui renvoie des valeurs suggérés
spécifiques aux lignes ou au mode saisie, etc. etc., etc., etc., etc., on
oubliera des cas primordiaux qui font de ma bibliothèque une bibliothèque de
décisionnel qui répond enfin à l’ensemble des cas.
·
Histoire
J’ai basé une grande partie de ma vie professionnelle
à cuisiner un gestionnaire d’accès aux données et ses grilles, sous les différents
environnements de développement, qui répond au maximum de problématiques
techniques, plus puissant que les stratégies de Microsoft en la matière, et que
j’ai entièrement écrit.
Plusieurs fenêtres de ce que j’ai développé par
exemple pour l’UBAF mettraient un temps de développement 5 à 10 fois plus
rapide avec un tel outil, qui mériterait d’être diffusé (servir de bibliothèque
d’une SSII, ou même voir ses principes intégrés dans Visual Studio), avec la
partie du code spécifique à l’entreprise qui en serait au
contraire très allégée et qui resterait aussi extrêmement souple
qu’avec la méthode MVVM.
C’est un projet réparti sur une quinzaine d’années que
j’ai pu mener parce que j’ai souvent eu l’occasion de travailler sur les
bibliothèques et les grilles dans les différents emplois que j’ai eu, ayant
plusieurs fois travaillé chez des éditeurs, partageant le code source avec leur
accord, et ayant racheté le code source de cette bibliothèque à mon premier
employeur.
Il s’agit particulièrement de profiter de mon
expérience de spécialiste des grilles de saisie et d’édition, un gars de
Microsoft ayant cité sur son blog (« en mettant dans l’explorateur d’objets une
grille genre Fred et ses tests unitaires et … » en anglais) ma performance dans
la conception d’un test unitaire pour les grilles de Microsoft, parmi mes
suggestions, bien que je ne sois pas spécialiste des tests, cette expérience
des grilles de saisie et d’édition, de la mise à profit que j’ai pu y appliquer
en durée au sein des entreprises, les moyens techniques que j’ai eu à
disposition de pouvoir remodeler des tas de choses jusqu’au dernier moment, dû
à la solidité aussi du produit, disons-le, car il s’agit d’une thématiques à
options et cas particuliers de revalorisation permanente en fonction de la connaissance
possible du contexte, avec beaucoup d’imagination à astuces très logiques et
bien soudées, donc aussi la mise à profit d’un comportement auto-adaptable à
tous les cas haut en effet convivialité effet Apple, tout en restant boîte à
outils complète effet Wall-E.
Il s’agit particulièrement de profiter de la synergie
inventée, associée et mise en œuvre, tout en profitant de la stabilité cousue
au fil de l’eau entre toutes ces options.
·
Segmentation du projet
Sur le principe, ma bibliothèque contient une
réécriture des DataTable, DataColumn, DataRow, des fort-typages de DataColumn,
un héritage de DataTable générique pour fort-typage de ligne, un héritage de
DataTable qui applique la création dynamique de requêtes, un héritage de
DataTable qui simule un outil de jointure de tables énormément surnaturaliste,
avec pas mal de possibilités plus que naturelles
Je déconseille vivement d’utiliser System.Data.DataSet
et ses classes connexes, mais c’est affaire d’existant et d’environnement qui
me font choisir entre EntityModel, LinqToSql, WCF ou ma bibliothèque. Je
conseille facilement LinqToSql à EntityModel si la problématique est simple. Je
ne considère pas que EntityModel versus Framework 4.5 ou inférieur soit
fantastique. Je conseille largement une solution entièrement par code, telle
que ma bibliothèque, ou telle que se réécrit désormais le nouvel EntityModel
versus Framework 5, c'est-à-dire que c’est le code qui fait l’assistant, mais
on constatera que Microsoft depuis 1990 propose un nouvel outil d’accès aux
données tous les 3 ans, en abandonnant le précédent. Dans cette mesure où l’on
constate que Microsoft est très instable à ce propos, je n’ai aucune honte à
proposer ma solution, qui est très autarcique.
Ces classes de base sont relayés par les outils
suivants dans le projet CollectionEngineLayer : Couche abstraite de
l’interface, couche abstraite de lecture/écriture de requêtes, valeurs
dynamiques avec beaucoup de propriétés liées non pas à une cellule mais à une
valeur, lecture/écriture du formatage d’une grille, ressources écrites/lues
avec héritage multi-niveau, ressources-options, et le répertoire d’outils
spécifiques et indépendants.
Dans des projets séparés : Weak-Events, langage
externe paramétrable, collection arbre binaire personnelle, concrétisation de
l’interface en WPF, existence d’une ancienne version en WinForms, couche de
lecture/écriture des présentations formatées en base, couche de gestion
dynamique des tables, couche de mapping statique des tables, générateur de
mapping à partir d’un fichier de modèle et d’un fichier de données, couche
visuelle indépendante de l’exécutable, lanceurs exécutables
(FdReportSqlServerAdmin, FdReportsSqlServer, FdReportOracleAdmin,
FdReportOracle).
·
Il y a
un gestionnaire de collection, de listes et ses fonctions
courantes, qui ne connaît ni les couches de données ni les couches
visuelles ni le fonctionnel.
·
Du fait
que je considère qu’on ne peut se passer dans la classe maîtresse de la
collection d’un accès à un groupe de propriétés concernant chaque champ, ainsi
qu’accéder aux champs et à leur groupe de propriété par l’intermédiaire d’un
numéro ou de son nom sous la forme d’une clé, mais que le modèle
System.Data.Datatable est caduque, j’ai copié ce modèle en le fusionnant
avec le modèle à typage fort.
·
Il y a
une couche de gestion visuelle indépendante qui connaît le process de
gestion de collection (car ses objets lui sont adaptés), mais ni les
couches de données ni le fonctionnel.
·
Il y a un
gestionnaire de la partie base de données qui ne connaît rien.
·
Il y a un
générateur automatique de couche d’objets d’accès aux données fortement
typée, qui travaille avec un fichier plat généré par une requête et un fichier
modèle.
·
Il y a
une couche d’objets d’accès aux données fortement typée de type Model
générée par le générateur automatique, qui connaît le process de gestion de
collections mais du visuel, il ne connaît que les booléens gras, italique et
couleur de fond mais aucun objet. S’il s’agit de se connecter à une couche WCF
ou EntityModel, il s’agit ici d’une seconde couche de données qui s’y connecte.
·
Le fonctionnel
d’entreprise associé aux données est implanté s’il est limité par classes
partielles au-dessus de cette couche d’objets, de façon indépendante, sinon par
héritage des objets fortement typés, ou par héritage des FD.Data.DataTable, ou
par classe fonctionnelle de type ViewModel.
·
Quelques principes mis en œuvre
·
Les
collections stockant les vues peuvent emboîter des classes identiques à
elles-mêmes en tant que valeurs suggérées à l’utilisateur dans les zones
de choix. Elles sont potentiellement déduites automatiquement des clés externes
grâce au générateur automatique, avec possibilité d’intervenir et de
déconnecter ou de reconnecter le plus simplement possible la totalité des
composants (exemple : La colonne servant de libellé peut être reconnue
automatiquement ou forcée…)
·
On décrit
aussi dans cette couche d’objets les objets qui utilisent les colonnes
provenant de plusieurs tables en décrivant des jointures, qui après
s’adaptent à n’importe quelles données établissant une telle jointure.
·
L’exécutable rassemble tous ces
gestionnaires, la couche d’accès aux données et les DLLs, et ils se mettent
d’eux-même à fonctionner ensemble de façon incorporée et finalisée.
·
Un grand
intérêt du projet est de pouvoir faire dépendre n’importe quelle vue, jointure
ou table tout autant d’une implantation de code unique par sa classe dans la
couche d’objets d’accès aux données et/ou de ressources externalisées ou
en bases de données, enregistrées en groupe par l’administrateur puis
rechargées.
·
J'ai
constaté que l'effet des bugs s'accroit exponentiellement avec leur nombre. Ils
s'amplifient l'un l'autre, ils génèrent des ombres de perturbations qui se
superposent. De même, un Framework qui sait sur quelle langue danser retrouve
toujours une réponse écrite de la même lumière adaptée lorsqu'une même question
se pose. Microsoft a par exemple enfin trouvé tous les mots de la langue à
utiliser pour exprimer les coordonnées directement et uniquement avec les
objets qui la composent, car les collections WPF utilisent les objets comme
coordonnées, plutôt qu'un mélange entre numériques, références et objets
desquels il fallait par le passé avoir toujours tous les types en paramètres
surchargés. Dans ce style de Framework de langue unique, une idée est de
dessiner des objets de sens exact. La résolution des problèmes se faisant
toujours et uniquement par la transcendance qui apporte aux objets l'expression
de plus en plus exacte et détaillée, lorsqu'il faut la relever, de ce pour quoi
ils sont faits. Contrairement à d’habitude, les astuces, les inventaires de
possibilités ou les quiproquos ne doivent être appelés que lorsqu'on ne
parvient plus à trouver une solution par la stratification de davantage de
sens. On perd souvent beaucoup de temps inutilement à préparer longtemps à
l'avance le niveau de détail, alors qu'on peut le rendre variable.
·
Il y
aurait sans doute de nombreuses petites transmutations collaboratives à
réaliser pour que mon projet se sente bien dans ses bottes de maraîcher, mais
il n’y a jamais eu de vraie pluie, ici, on ne sait pas ce que c’est. Il est
déjà opérationnel, et possède un exécutable de mode autonome.
·
Commentaire de code par l’équipe
Microsoft
Revue du code par le Support Microsoft Premier
Points de vue rapportés : Code très bien écrit, solide, complexe composé par sa richesse, pas particulièrement compliqué (mais tout de même en cours de débogage en ce qui concerne l’une des couches, normal pour un mode de programmation par description de comportement à l’initialisation, qui a d’ailleurs surtout des avantages de simplicité-même, de plus il y a ici le choix de description de comportement jusqu’à l’infinitif du sens-même), compréhensible, avec de bonnes couches, avec de bonnes séparations de couches, sans failles de sécurité, sans aucune erreur grave trouvée, avec très peu d’erreurs, tous les choix techniques, algorithmiques, technologiques valides, écrit en peu de temps fonction de la taille, avec très peu de mauvaises habitudes standards, mais avec des petites tâches grasses. & Préconisations pour y remédier. Christophe a aussi noté une adéquation de style avec le code écrit par Microsoft, et tout en affirmant que les grilles, ça ne marche jamais parfaitement, avoue que ce n’est pas du tout à la portée de tous d’écrire une telle bibliothèque.
Points de vue d’utilisateurs : « There was no slowness issue experienced, the screen refresh and response time were normal. ». « Je viens de créer un report personnalisé et franchement c’est génial. Le seul bémol est qu’on ne puisse pas faire une recherche de radical via une case ou un menu déroulant, mais c’est déjà pas mal ! » (en fait, la fonction existe !)
·
·
Exemples de concepts uniformisés
par le projet
·
Généralisation
du principe de source de valeurs suggérées de même classe de base que la table
source.
·
Abonnement
possible à plusieurs niveaux et plusieurs étapes pour retoucher la valeur, la
présentation abstraite, la validation, la manipulation, avec toujours
l’information de grille, de colonne, de valeur.
·
Possibilité
de demander à la colonne de formater une valeur sans connaître la ligne.
·
Etape de
retouche de la valeur avec abonnement.
·
Nombreuses
options de la colonne.
·
Nombreuses
options de la grille.
·
Impression
avec présentation automatique paramétrable.
·
Export
PDF avec présentation automatique paramétrable.
·
Possibilité
d’enregistrer ses présentations de rapport.
·
Paramétrage
à l’écran tel que le rendu final des rapports (wysiwyg).
·
Possibilité
de paramétrer la présentation systématique par sous-charge d’une table.
·
Protection
possible des paramétrages de sous-charge.
·
Export
Excel.
·
Option
pour ajouter les colonnes qui ne figuraient pas dans la modélisation ou la
première fois et qui ont été ajoutées dans la vue ou la table après.
·
Option
pour ne pas charger les colonnes qui n’apparaissent pas.
·
L’utilisateur
peut enregistrer ses propres états filtrés.
·
Outil de
regroupement mémoire.
·
Mise à
profit du regroupement par base de données quand c’est nécessaire.
·
Outil de
tableau croisé.
·
Outil de
filtre mémoire.
·
Option
pour faire apparaître toutes les valeurs potentielles de la clé primaire, même
si elles n’apparaissent pas en base.
·
Jointures
efficaces paramétrables, qui permettent de tout charger avec une seule requête,
puis de modifier toutes les tables de la jointure, avec enregistrement séparé,
et réaffectation dynamique de la nouvelle ligne lorsque c’est la clé externe
qui change.
·
Gestion
des noms de colonnes identiques dans une jointure.
·
Les
regroupements mémoires et les tableaux croisés sont modifiables.
·
Lorsqu’un
DataTable est un proxy d’un autre, les retouches sont une union des deux.
Attention dans ce cas de ne pas faire de retouches qui se cumulent.
Et un millier d’autres
caractéristiques similaires gérées en générique.