Projet professionnel N°1 : FdReports - Caractéristiques optimales pour une bibliothèque de décisionnel et de rapports

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.

Print | posted on Friday, July 6, 2018 12:34 AM

Feedback

No comments posted yet.

Your comment:





 
Please add 5 and 6 and type the answer here:

Copyright © Frédéric Decréquy

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski