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.