Service de Tracking Dynamique

Bonjour,

Je m'apprête à créer un nouveau service en C# afin de faire du tracking, du logging extensible pour les événements à valeur d'affaires. Des événements pour lesquels aucun debug n'est nécessaire mais qui vont construire des statistiques.
En ce moment, les quelques statistiques sont compilées à partir de tables dans la base de données principales et bien entendu ça cause problème.

Donc nous avions construit un serveur de statistiques (SSAS) et plutôt que de garder les données sur le serveur principal, nous allons envoyer directment les données sur le serveur de statistiques.

À mon précédent emploi, nous avons un tel service écrit en Python. Puisque ce langage est dynamique par conception, il a été facile de pouvoir de créer des objets sur-le-champs à partir de données en JSON.

En C#, malgré que la sérialisation soit simple, le 'binding' ça me semble plus compliqué.

Donc, je vais construire un service en Web API (MVC 4.0) REST avec une seule méthode qui accepte une string JSON dans le body de la requête. Voici un example.

Code:

---

1 2	{"Context":"Load", "Msg":"Bonjour", "Other": "Boo"}

---

Le système devra pouvoir reconnaitre qu'il s'agisse d'un objet 'Load' et ultimement sauvegarder les information Msg et Other dans une table 'Load'.

Il y aura aussi des tables de configuration qui permettront au service de connaitre la nature des tags reçus. Par exemple, un contexte 'Load' doit fournir les valeurs de Msg et Other. Un contexte 'Visit' doit fourninr les valeurs IP et Browser.

Donc le service aura en mémoire une liste de contextes qu'il va accepter et traiter en conséquence.

Ma première approche aurait été d'utiliser de la réflexion sur les entités Entity Framework bindées sur les tables de fait (Load, Visit, etc.) afin de créer une instance d'entité, remplir des propriétés et utiliser le framework pour sauvegarder. Le problème est qu'Entity Framework ne mappe pas automatiquement les nouvelles tables. À chaque fois que l'on créerait une nouvelle table, il faudrait ouvrir la solution, générer les classes entité, recompiler et redéployer (à moins que je me trompe...).

Ma deuxième approche aurait été de rendre le service complèment dynamique en reproduisant en partie les facilités d'Entity Framework. La solution la plus rapide serait de générer du SQL dynamiquement et le passer par ADO.Net. Je voudrais éviter à tout prix de faire cela.

Je ne veux pas non plus avoir une structure de données trop générique (toutes les données dans la même table avec des types de propriétés) puisque ça serait désastreux pour les performances d'Analysis Services.

Donc, en bref, je cherche à créer un service qui puisse recevoir des requêtes dont les données JSON devrait correspondre à une table particulière dans une DB particulière et sauvegarder les données en conséquence, sans jamais avoir à recompiler le service lorsque de nouvelles tables/contextes s'ajoutent au système.

(Désolé pour le long post...)

Mes questions:
- Est-ce que le Dynamic Linq peut remplacer une implémentation de génération de SQL dynamique dans un contexte où les Types ne sont pas connus par le code?
- Est-ce que la création de Types (représentation de classe) au runtime est sécuritaire, stable et performante? (AssemblyBuilder, ModuleBuilder, TypeBuilder)
- Y a-t-il un quelconque moyen d'utiliser Entity Framework de façon 'optimiste', c'est-à-dire qu'il puisse générer des types au runtime à partir de l'emsemble des tables d'un BD ou d'un schema (SQL Server)?

Toute opinion sera la bienvenue. En attendant, je vais, malgré moi, commencer à implémenter une solution avec génération de SQL dynamique avant de me lancer dans la génération de types.

Merci