Suis-je le seul à me battre avec les TableAdapters, ces classes générées par Visual Studio 2005 pour les DataSets typés?
D'un côté, ce sont de beaux outils pour générer rapidement des formulaires d'accès aux données: après tout, il s'agit de la génération automatique d'une couche de mapping O/R (les grands mots sont sortis).
Mais dès qu'on creuse, c'est la déception:
D'un côté, ce sont de beaux outils pour générer rapidement des formulaires d'accès aux données: après tout, il s'agit de la génération automatique d'une couche de mapping O/R (les grands mots sont sortis).
Mais dès qu'on creuse, c'est la déception:
- Le TableAdapter se base sur un DataAdapter (après tout il ne fait pas grand chose de plus), mais le DataAdapter sous-jacent est private;
- Le TableAdapter n'implémente aucune interface (il hérite juste de ComponentModel, ce qui ne nous avance pas à grand chose);
- Il n'y a pas de moyen de demander à un DataSet typé la liste de ses TableAdapters.
Autrement dit, les TableAdapters sont un bel exemple de non-architecture, d'anti-design pattern.
En ce moment, j'ajoute la prise en charge de l'accès déconnecté aux TableAdapters, et c'est casse-tête à cause des points ci-dessus.
PS: si vous ne connaissez pas les TableAdapters, aprenez tout dans cet excellent article.
Comments
Je suis bien d'accord, et j'ai le même soucis "Le TableAdapter n'implémente aucune interface (il hérite juste de ComponentModel, ce qui ne nous avance pas à grand chose)".
J'ai notamment une liste de TableAdapter, et je suis obligé de la stocker dans une Liste générique de Component :-(. Reste plus que la reflexion pour faire du code générique. :-(
Sybaris