Créer DataBridge en C#

DataBridge: Une couche de synchronisation universelle construite autour des charges dynamiques JSON et ExpandoObject

DataBridge a été développé comme une plateforme de synchronisation réutilisable pour déplacer les données commerciales d'un environnement administratif local vers des systèmes distants tels que les services HTTP, Microsoft SQL Server et MySQL. Il a été construit comme un pont durable entre des environnements techniques très différents, avec la flexibilité de continuer à fonctionner même lorsque la forme exacte des données n'est pas connue à l'avance.

L'une des décisions techniques les plus importantes à l'intérieur de ce projet a été l'utilisation d'un modèle de charge utile dynamique basé sur des dictionnaires, JSON sérialisation, et ExpandoObject instances créées à travers l'ObjectFactory interne. Cette conception a rendu le pont beaucoup plus universel qu'une intégration traditionnelle qui dépend des classes DTO rigides pour chaque table et chaque type de disque.

Contextes du projet

Dans de nombreux environnements commerciaux, le système source contient des données opérationnelles précieuses mais n'est pas un backend direct approprié pour les applications Web, les portails, les tableaux de bord ou les intégrations. Les systèmes hérités ont souvent des limites de connectivité, des structures de table qui ne sont pas conçues pour les applications modernes et des contraintes de déploiement qui rendent l'exposition directe risquée.

DataBridge résout cela en agissant comme une couche de traduction et de synchronisation. Il lit les données de source, comprend les structures de table, prépare les tableaux distants, les pistes qui doivent être synchronisées et envoie les données vers la cible configurée. Selon l'installation, cette cible peut être un point d'extrémité de pont basé sur HTTP, Microsoft SQL Server ou MySQL.

Ce qui rend l'implémentation particulièrement forte, c'est que le pont ne nécessite pas un modèle de classe hardcodé pour chaque forme de disque possible. Au lieu de cela, il peut emballer les enregistrements de manière dynamique et les déplacer à travers le pont dans une structure qui reste flexible jusqu'à ce que la partie réceptive décide comment le persister.

Le défi de base: déplacer des données sans coder dur chaque schéma

Les intégrations traditionnelles deviennent souvent fragiles parce qu'elles s'attendent à un modèle d'objet fixe. Chaque table, chaque liste de champs et chaque type de charge utile doivent être modélisés en code à l'avance. Cette approche fonctionne pour les petits systèmes, mais elle devient coûteuse lorsque l'intégration doit prendre en charge de nombreuses tables, des structures en évolution, des administrations différentes et de multiples arrière-plans à distance.

DataBridge adopte une approche plus universelle. Pendant la synchronisation, les lignes sources sont d'abord collectées dans un dictionnaire<string, objet>. Chaque ligne devient une carte de champ dynamique plutôt qu'une instance de classe rigide. Les chaînes sont nettoyées, les dates sont normalisées en valeurs de chaîne sûres pour le transport, les booléens sont préservés, les valeurs numériques sont converties de manière cohérente et un contexte administratif tel que ADMINCODE est ajouté avant l'envoi du dossier.

Cette structure intermédiaire du dictionnaire est la clé. Il permet au pont de transporter des données dont la forme finale est déterminée par les métadonnées et la configuration du temps d'exécution au lieu d'hypothèses de compilation. En d'autres termes: DataBridge peut transporter des enregistrements qu'il n'a pas besoin de pleinement know comme fortement typé C# modèles.

Le rôle de l'objetFactory

L'ObjectFactory interne est l'endroit où cette flexibilité devient pratique. Sa méthode CreateInstance prend un dictionnaire<string, objet> et le convertit en un ExpandoObject dynamique. Chaque paire de valeurs clés du dictionnaire est copiée dans l'objet extensible en temps d'exécution.

Il s'agit d'un élément d'infrastructure trompeusement simple, mais il a un effet architectural majeur. Une fois que la charge utile devient un ExpandoObject, DataBridge peut le placer dans des objets de demande sans avoir besoin d'une classe compilée séparée pour chaque table ou opération. Le modèle de demande conserve des champs tels que des données et des paramètres comme propriétés d'objets génériques, et le pont sérialise la demande complète à JSON en utilisant Newtonsoft.JSON.

Cela signifie que DataBridge peut emballer:

• Collections dynamiques d'enregistrements pour les lots de synchronisation.
• Charges utiles de paramètres générées en temps d'exécution pour des opérations telles que la création de tables à distance.
• Les métadonnées liées au schéma pouvant varier par tableau ou par administration.
• Structures qui ne sont pas pratiques pour se verrouiller dans une hiérarchie de classes statiques.

En termes pratiques, ObjectFactory transforme un dictionnaire simple en un graphique d'objet prêt à être transporté qui se comporte comme native JSON. Cela rend le pont adaptable sans rendre la base de code chaotique.

Pourquoi ExpandoObject est important ici

L'utilisation d'ExpandoObject n'est pas seulement une fonctionnalité de commodité.

Un ExpandoObject permet aux propriétés d'exister dynamiquement en temps d'exécution. Cela convient parfaitement au travail de synchronisation, où le pont peut déplacer des enregistrements à partir de tables avec des ensembles de champs très différentes. Au lieu de maintenir des dizaines ou des centaines de modèles de charge utile dédiés, le pont peut construire la forme des données à partir du contenu réel de la rangée et l'envoyer immédiatement.

Cela donne à DataBridge plusieurs avantages importants:

• Il peut supporter une large gamme de tables sans entretien répétitif du modèle.
• Il peut contenir des champs découverts à partir de la structure de la base de données plutôt que des champs prédéfinis par le code source.
• Il reste plus facile de l'étendre lorsque de nouveaux tableaux ou variantes sont introduits.
• Il peut utiliser le même pipeline de demandes pour différentes opérations et différents objectifs de transport.

C'est précisément la raison pour laquelle le pont est vraiment universel dans sa manutention de charge utile. Le format de transport est suffisamment flexible pour accueillir des structures JSON inconnues ou en évolution tout en restant suffisamment structuré pour un traitement contrôlé du côté récepteur.

Comment la charge utile dynamique traverse le pont

Le flux intérieur de DataBridge peut être compris comme un pipeline de transformation par étapes.

1. Les lignes de source sont lues à partir de la base de données administrative locale.
2. Chaque ligne est convertie en un dictionnaire de noms de champs et de valeurs.
3. Le dictionnaire est normalisé de sorte que les chaînes, les dates, les booléens et les valeurs numériques soient sûrs et cohérents pour le transport.
4. ObjectFactory.CreateInstance convertit ce dictionnaire en ExpandoObject.
5. L'objet dynamique est ajouté à une charge utile de demande qui contient également le nom de table, l'administration, la clé principale et les métadonnées de structure.
6. La requête est sérialisée à JSON et envoyée à l'arrière-plan configuré.
7. Le backend récepteur interprète cette charge utile dynamique et la transforme en opérations d'insertion, de mise à jour ou de suppression SQL.

Parce que le modèle de requête stocke les données et les paramètres comme des objets génériques, la même enveloppe de transport peut être réutilisée pour de nombreuses actions de pont. Cela inclut la synchronisation des enregistrements, la création de tables et la suppression de tables.

Unknown JSON In, Usable Data Out

Un aspect particulièrement fort de cette conception est que DataBridge est confortable de manipuler des structures similaires à JSON même lorsque la disposition exacte de la propriété n'est connue qu'en temps d'exécution. Le pont construit ces structures à partir de dictionnaires, les sérialise sans exiger un contrat de classe strict, puis les reconstruit à l'autre extrémité en collections de valeurs clés viables à nouveau.

Du côté récepteur, les chemins Microsoft SQL Server et MySQL convertissent la charge utile de l'enregistrement dynamique en un dictionnaire afin que la logique de génération SQL puisse travailler avec elle génériquement. Cela signifie que le milieu du pont peut rester flexible, tandis que la couche de persistance a toujours un contrôle précis sur les noms de champs, le formatage de valeur, les vérifications de clés primaires et les décisions d'insertion contre mise à jour.

C'est l'équilibre architectural important: DataBridge est dynamique dans le transport, mais délibéré dans l'exécution.

Universel par conception et non par commercialisation

Appeler une plateforme universale signifie seulement quelque chose si les internes soutiennent cette affirmation. Dans DataBridge, cette universalité est visible dans la mise en œuvre:

• La même structure de requête peut cibler HTTP, Microsoft SQL Server ou MySQL.
• La même stratégie de charge utile peut représenter des enregistrements provenant de tables différentes sans classes de modèles dédiées.
• La même construction d'objet dynamique est réutilisée pour les lots de données et les paramètres opérationnels.
• Le même moteur de synchronisation peut fonctionner à travers différentes administrations et modèles de déploiement.

C'est ce qui rend la stratégie ObjectFactory et ExpandoObject si importante. Elle élimine le couplage inutile entre le schéma source et le schéma de transport. Au lieu de forcer l'ensemble du pont à changer chaque fois que la forme des données change, le pont peut continuer à fonctionner sur une représentation dynamique mais contrôlée de la charge utile.

Les avantages opérationnels de l'approche dynamique

La maniabilité flexible du JSON n'est pas seulement une préférence technique, elle crée de véritables avantages opérationnels.

• Les nouveaux champs ou les champs modifiés peuvent être adaptés avec beaucoup moins de réfactoration.
• Le pont peut évoluer jusqu'à plus de tables et à plus de variations spécifiques au client sans exploser le modèle de classe.
• La sélection de l'arrière-plan reste un problème de configuration plutôt qu'un problème de redessin de charge utile.
• La couche de transport reste réutilisable à travers les fonctionnalités de synchronisation.
• Le projet reste plus facile à maintenir parce que la logique du pont est centrée sur la découverte et la transformation de structures plutôt que sur des définitions d'objets infinies.

Pour un système dont le travail est de connecter des logiciels commerciaux plus anciens à des plateformes modernes, cela compte beaucoup.

Plus qu'un outil de transfert de données

Au-delà de la stratégie dynamique JSON, DataBridge comprend également la mécanique plus large requise pour une synchronisation fiable. Il découvre les définitions de table, identifie les clés primaires, prépare des structures à distance, suit le travail de synchronisation et envoie des enregistrements en lots. Il peut prendre en charge les déploiements de bases de données uniques ou des bases de données distantes séparées par administration. En d'autres termes, le projet combine la flexibilité du temps d'exécution avec une discipline pratique de synchronisation.

Le résultat n'est pas seulement un connecteur, mais une plateforme de middleware qui aide les données administratives anciennes à devenir utilisables pour les sites Web, les portails, les environnements de reporting et les applications commerciales personnalisées.

Conclusion

La partie la plus distinctive de DataBridge est la façon dont il traite les données qui ne doivent pas être entièrement hardcodées à l'avance. En construisant des enregistrements en tant que dictionnaires, en les convertissant à travers ObjectFactory en instances ExpandoObject, en les sérialisant en JSON, puis en les reconstruisant génériquement du côté récepteur, le pont gagne un niveau d'adaptabilité qui manque à de nombreuses intégrations traditionnelles.

Cette manipulation flexible de l'inconnu JSON est ce qui rend le pont vraiment universel. Il permet à DataBridge de s'asseoir entre des systèmes très différents, de garder la couche de transport légère et dynamique, et de produire des résultats fiables et contrôlés dans l'environnement cible. Pour une plateforme d'intégration destinée à survivre à la variation des schémas, aux multiples backends et aux exigences commerciales en évolution, c'est l'une de ses décisions architecturales les plus fortes.