Bonjour,

Je travaille actuellement à la conception d'une couche Data Layer permettant de récupérer et convertir des données provenant d'une requête en objets métier.
Les principales contraintes sont:
- la performance: nécessité de pouvoir récupérer des centaines de millier de lignes en "peu" de temps
- la facilité d'utilisation: pouvoir binder et accéder simplement aux propriétés des objets métiers remontés.

Lorsque l'objet métier est clairement défini (Client, Produit...), aucun problème:
- Je définis les propriétés de l'objet métier,
- J'exécute une méthode de type IList<T> ExecuterSelect<T>(SQL)
- J'ai une classe de type Parser qui se charge d'affecter les champs d'un DataReader à la bonne propriété de l'objet T et qui est utilisée dans la méthode ExecuterSelect.

Le problème est que je souhaiterais ajouter de la flexibilité, et avoir la possibilité de remonter également des résultat "génériques", non clairement typés métier, afin de pouvoir traiter des données "brutes".
Mais je ne sais pas comment construire le type d'objet de retour...

J'ai pensé à plusieurs solutions:
- Utiliser une IList<Dictionnary<String, object>>: chaque objet T est un dictionnaire où la clé est le nom du champ, et la valeur est la valeur du champ. Problème: l'utilisation n'est pas la même que pour un objet métier clairement défini. Par exemple, pour un objet métier, le binding se fait via le nom de la propriété (NOM_CLIENT), et là elle se fait via l'opérateur [] ([NOM_CLIENT]). Cela oblige à avoir un traitement différent dans les grilles selon que je récupère des objets métier ou des objets génériques.

- Utiliser un DynamicObject, implémenant un Dictionnary; en faisant un override de la méthode TryGetMember: règle le problème du binding, mais performances moins bonnes, et ne règle pas tous les problème de différences de traitement.

- Créer une nouvelle classe en dynamique avec Reflection.Emit: Impossible de définir un "type de base" vide, auquel on rajouterait des propriétés à la volée. Il faut créer un nouveau type à chaque requête, ce qui fait qu'on ne sait plus quel type exactement on utilise... Et puis je trouve ça un peu lourd.

- Utiliser un retour de type DataTable: le must pour ce qui est de l'utilisation, mais les performances ne sont pas au rendez-vous. Dépassé un certain nombre de dizaines de milliers de ligne, l'objet explose.


Avez-vous une idée de "structure de données" générique, qui puisse s'utiliser de la même façon qu'une structure de donnée typée, et qui allie performance et généricité dans son utilisation??
Par exemple, un objet qui ne contiendrait aucune propriété définie en dur, celles-ci seraient créées à la volée au moment du parsing à partir du DataReader.

Merci d'avance!
(PS: je peux éventuellement donner des exemples de code si besoin, mais la question se situe plus au niveau du "concept").