·
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 point
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 5 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
quant à 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.
·
Direction par le déclaratif. Le
principe de designer reste de mise, mais donc de façon codée : Les
comportements sont bien davantage décrits que les actions canalisées et
décorées, mais c’est possible aussi. Cela simplifie et allège énormément
l’écriture, et situe l’action bien davantage sur le sujet naturel, en permettant
une définition unique, par code, dans le modèle. Le moteur est alors libre de
faire intervenir les composants décrits dès que le moindre besoin se fait
sentir, libérant ainsi la synergie exponentielle des possibilités et de
l’interactivité, particulièrement intéressante lorsque les éléments s’emboîtent
tous, et le résultat reste humain lorsqu’ils s’emboîtent de façon assez
standard.
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ées 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.