Développement de DataBridge en C#

DataBridge : une couche de synchronisation universelle fondée sur JSON dynamique et ExpandoObject

DataBridge a été développé comme une plateforme de synchronisation réutilisable pour transférer des données métier d’un environnement de gestion local vers des systèmes distants : services HTTP, Microsoft SQL Server ou MySQL. Le projet dépasse l’outil d’export ponctuel. Il constitue un lien durable entre des environnements techniques très différents, avec la souplesse nécessaire pour fonctionner même lorsque la structure exacte des données n’est pas connue à l’avance.

L’un des choix techniques majeurs du projet est un modèle de données à transmettre dynamique, fondé sur des dictionnaires, la sérialisation JSON et des instances ExpandoObject créées par l’ObjectFactory interne. Il rend la passerelle bien plus universelle qu’une intégration traditionnelle reposant sur des classes DTO rigides pour chaque table et chaque type d’enregistrement.

Contexte du projet

Dans de nombreuses entreprises, le système source contient des données opérationnelles précieuses sans convenir comme backend direct pour des applications web, portails, tableaux de bord ou intégrations. Les systèmes anciens présentent souvent des limites de connexion, des structures de tables peu adaptées aux applications modernes et des contraintes de déploiement qui rendent leur exposition directe risquée.

DataBridge y répond par une couche de transformation et de synchronisation. Il lit les données source, analyse les structures des tables, prépare les tables distantes, suit les enregistrements à synchroniser et les transmet à la destination configurée. Selon l’installation, celle-ci peut être un point d’accès de passerelle HTTP, Microsoft SQL Server ou MySQL.

La force de cette implémentation est de ne pas exiger de classe codée en dur pour chaque structure d’enregistrement possible. La passerelle peut constituer les enregistrements dynamiquement et les transférer sous une forme qui reste souple jusqu’à ce que le destinataire décide comment les conserver.

Le défi central : transférer les données sans coder chaque schéma à l’avance

Les intégrations classiques deviennent souvent fragiles parce qu’elles attendent un modèle d’objets fixe. Chaque table, liste de champs et type de données transmis doit être modélisé à l’avance dans le code. Cela convient aux petits systèmes, mais devient coûteux lorsqu’il faut prendre en charge de nombreuses tables, des structures évolutives, plusieurs dossiers de gestion et plusieurs backends.

DataBridge adopte une approche plus générale. Pendant la synchronisation, les lignes source sont d’abord regroupées dans un Dictionary<string, object>. Chaque ligne devient une correspondance dynamique entre champs et valeurs plutôt qu’une instance de classe rigide. Les chaînes sont nettoyées, les dates converties en chaînes adaptées au transport, les booléens préservés et les nombres convertis de manière cohérente. Le contexte du dossier de gestion, tel qu’ADMINCODE, est ajouté avant l’envoi.

Cette structure intermédiaire en dictionnaire est essentielle. Elle permet de transporter des données dont la forme finale est déterminée par les métadonnées et la configuration d’exécution, plutôt que par des hypothèses fixées à la compilation. DataBridge peut ainsi transférer des enregistrements sans avoir à les connaître entièrement sous forme de modèles C# fortement typés.

Le rôle d’ObjectFactory

L’ObjectFactory interne concrétise cette souplesse. Sa méthode CreateInstance prend un Dictionary<string, object> et le convertit en ExpandoObject dynamique. Chaque paire clé-valeur du dictionnaire est copiée dans l’objet extensible à l’exécution.

Cette infrastructure paraît simple, mais son effet sur l’architecture est important. Une fois les données transformées en ExpandoObject, DataBridge peut les intégrer aux objets de requête sans classe compilée distincte pour chaque table ou opération. Le modèle de requête conserve des champs tels que data et parameters comme propriétés de type object, puis sérialise l’ensemble en JSON avec Newtonsoft.Json.

DataBridge peut ainsi préparer :

• des collections dynamiques d’enregistrements pour les lots de synchronisation ;
• des paramètres générés à l’exécution pour des opérations telles que la création de tables distantes ;
• des métadonnées de schéma variables selon la table ou le dossier de gestion ;
• des structures difficiles à enfermer dans une hiérarchie de classes statique.

En pratique, ObjectFactory transforme un dictionnaire simple en un graphe d’objets prêt à transmettre, qui se comporte comme du JSON natif. La passerelle reste adaptable sans rendre le code désordonné.

Pourquoi ExpandoObject est essentiel ici

ExpandoObject n’est pas un simple confort de programmation. Il est au cœur du caractère universel de DataBridge.

ExpandoObject permet de créer des propriétés dynamiquement à l’exécution. Cela convient parfaitement à la synchronisation d’enregistrements issus de tables aux champs très différents. Au lieu de maintenir des dizaines ou centaines de modèles spécialisés, la passerelle construit la structure à partir du contenu réel de la ligne et la transmet immédiatement.

DataBridge en tire plusieurs avantages :

• prendre en charge de nombreuses tables sans maintenance répétitive des modèles ;
• transporter des champs découverts dans la structure de la base plutôt que prédéfinis dans le code ;
• faciliter l’extension à de nouvelles tables ou variantes ;
• utiliser la même chaîne de requêtes pour différentes opérations et destinations.

C’est ce qui rend la gestion des données transmises réellement universelle. Le format est assez souple pour accepter des structures JSON inconnues ou évolutives, tout en restant suffisamment structuré pour permettre un traitement maîtrisé à la réception.

Le parcours des données dynamiques dans la passerelle

Le fonctionnement interne de DataBridge suit une chaîne de transformations successives.

1. Les lignes source sont lues dans la base de gestion locale.
2. Chaque ligne est convertie en un dictionnaire de noms de champs et de valeurs.
3. Le dictionnaire est normalisé pour assurer un transport sûr et cohérent des chaînes, dates, booléens et nombres.
4. ObjectFactory.CreateInstance transforme ce dictionnaire en ExpandoObject.
5. L’objet dynamique est ajouté à une requête qui comprend aussi le nom de la table, le dossier de gestion, la clé primaire et les métadonnées de structure.
6. La requête est sérialisée en JSON et envoyée au backend configuré.
7. Le backend destinataire interprète les données dynamiques et les convertit en opérations SQL d’insertion, de mise à jour ou de suppression.

Comme le modèle de requête conserve data et parameters sous forme d’objets génériques, la même enveloppe de transport sert à de nombreuses actions : synchronisation d’enregistrements, création et suppression de tables. L’implémentation évite les spécialisations excessives et maintient une logique cohérente.

Du JSON inconnu aux données exploitables

Un point fort de cette conception est sa capacité à traiter des structures de type JSON dont les propriétés exactes ne sont connues qu’à l’exécution. La passerelle les construit depuis des dictionnaires, les sérialise sans exiger un contrat de classe strict, puis les reconstitue à l’arrivée en collections clé-valeur exploitables.

À la réception, les traitements Microsoft SQL Server et MySQL reconvertissent les données dynamiques des enregistrements en dictionnaires pour que la génération SQL puisse les traiter de manière générique. Le cœur de la passerelle reste souple, tandis que la couche de persistance contrôle précisément les noms de champs, le formatage des valeurs, la vérification des clés primaires et le choix entre insertion et mise à jour.

Cet équilibre est essentiel : DataBridge est dynamique pendant le transport et précis dans l’exécution.

Une universalité inscrite dans la conception

Qualifier une plateforme d’universelle n’a de sens que si son fonctionnement interne le confirme. Dans DataBridge, cela se voit dans l’implémentation :

• une même structure de requête peut cibler HTTP, Microsoft SQL Server ou MySQL ;
• une même stratégie de données représente les enregistrements de différentes tables sans classes dédiées ;
• la même construction d’objets dynamiques sert aux lots de données et aux paramètres d’opération ;
• le même moteur de synchronisation s’adapte à plusieurs dossiers de gestion et modèles de déploiement.

C’est l’intérêt de la stratégie ObjectFactory et ExpandoObject : supprimer le couplage inutile entre le schéma source et le schéma de transport. Au lieu de modifier toute la passerelle chaque fois que les données changent de forme, on conserve une représentation dynamique mais maîtrisée.

Avantages opérationnels de l’approche dynamique

La souplesse du traitement JSON dépasse une préférence technique. Elle apporte des avantages concrets.

• Les champs nouveaux ou modifiés nécessitent beaucoup moins de remaniement du code.
• La passerelle peut couvrir davantage de tables et de variantes propres aux clients sans multiplier démesurément les classes.
• Le choix du backend reste un réglage de configuration plutôt qu’un problème de reconception des données transmises.
• La couche de transport reste réutilisable entre les fonctions de synchronisation.
• Le projet est plus facile à maintenir, car sa logique repose sur la découverte et la transformation des structures plutôt que sur une succession interminable de définitions d’objets.

C’est déterminant pour un système chargé de relier des logiciels métier anciens à des plateformes modernes. Un logiciel d’intégration doit absorber la diversité ; DataBridge a été conçu pour cela.

Au-delà du transfert de données

DataBridge comprend aussi tous les mécanismes d’une synchronisation fiable : découverte des définitions de tables, identification des clés primaires, préparation des structures distantes, suivi du travail de synchronisation et envoi par lots. Il prend en charge une base commune ou des bases distantes séparées par dossier de gestion. Le projet associe ainsi la souplesse à l’exécution à une synchronisation rigoureuse.

Le résultat est une plateforme intermédiaire, au-delà d’un simple connecteur, qui rend les anciennes données de gestion exploitables par des sites web, portails, outils de reporting et applications métier sur mesure.

Conclusion

La particularité de DataBridge réside dans sa gestion de données qui n’ont pas à être entièrement codées à l’avance. Les enregistrements sont construits comme dictionnaires, convertis par ObjectFactory en instances ExpandoObject, sérialisés en JSON puis reconstruits de manière générique à la réception. La passerelle obtient ainsi une adaptabilité qui manque à de nombreuses intégrations classiques.

Cette gestion souple de JSON inconnu rend la passerelle réellement universelle. DataBridge peut relier des systèmes très différents, garder une couche de transport légère et dynamique et produire des résultats fiables et maîtrisés dans l’environnement cible. Pour une plateforme destinée à supporter les variations de schéma, plusieurs backends et des besoins métier évolutifs, c’est l’un de ses choix d’architecture les plus solides.