Discussion :

[olibara]

Bonjour

Jusqu'ici je n'emploie que tres rarement les BindingSouce car elle ne m'apportent rien dans la majorité des cas

- Binder une datatable sur un DGV

- Ou m'empechent une astuce amusante
Binder une datatable sur plusieurs combo permettant la recherche d'un row sur plusieurs colonnes

Parfois je l"emploie pour binder des List<T> sur un DGV afin de permettre le Add et Delete

Question :

Vaut il mieux utiliser un BindingSource
Ou ajouter l'interface IbindingList dans la classe qui definit ma liste

Quels seraient les pour et contre ?

[Guulh]

BindingSource est surtout utile quand plusieurs contrôles sont bindés à un même objet métier / une même liste d'objets métier. Perso j'aime bien m'en servir ; quand on code la partie "UI", ça uniformise pas mal. Ca gère un élément "Current", par exemple, que je préfère utiliser plutôt que chercher dans la grille quel est l'élément courant.

Disons que le binding fonctionne avec IList, IBindingList, IBindingListView ; chacune de ces interfaces est un héritage de la précédente. IList ne gère que le parcours et l'ajout, IBindingList gère en plus le tri et la notification, IBindingListView gère aussi le tri multiple et le filtrage. Mais BindingSource, en lui-même, ne filtre pas ; il se contente de rediriger toutes les demandes de tri et de filtre à sa source. C'est qu'un tuyau.

Après, il est certain qu'il manque au framework une implémentation de IBindingListView. A ma connaissance, seule la DataView l'implémente...

[olibara]

Merci Guulh

Pratiquement
Ce que j'avais constaté, c'est ceci

1- Si tu bind une liste direct sur un dgv : pas de tri pas d'ajout pas de delete
2- Si tu bind une liste a un dgv via binding source : pas de tri MAIS ajout et delete autorisé
3- Si tu derive IBindDingList dans la liste tu peux faire un bind direct de la liste sur le DGV avec tri,ajout et delete (pour autant que les methodes respectives soient définie dans l'interface)

[Guulh]

J'ai constaté les mêmes choses (heureusement, quelque part ) effectivement l'utilisation d'une BindingSource enrichit un peu le comportement des List.

Mais c'est une couche d'abstraction que j'aime bien. Tous les contrôles sont plugués à des BS, tous les BS sont plugués à des objets métier, et go (aussi bien les contrôles simples tels que la textbox, liés à un objet unique, et les contrôles de type liste tels que la listview, la dgv, etc.)

[SaumonAgile]

Mais c'est une couche d'abstraction que j'aime bien. Tous les contrôles sont plugués à des BS, tous les BS sont plugués à des objets métier, et go (aussi bien les contrôles simples tels que la textbox, liés à un objet unique, et les contrôles de type liste tels que la listview, la dgv, etc.)

Complètement +1
Cela permet en effet de découpler un peu l'interface et les objets métier.

[olibara]

Salut Saumont agile

Heueee ?
Dans tous les cas vraiment ?

Prenons un cas simple : une datatable et un DGV

Cas 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dgv.datasource=MaDataTable;

Cas 2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
BindingSource MaBDS=new BindingSource();
MaBDS.DataSource=MaDataTable;
dgv.DataSource=MaBDS;

Qu'est ce que le cas 2 apporte en plus sinon 2 lignes de code en plus, un objet complementaire a gerer par le FW, et peut etre la satisfaction académique d'avoir ajouté une abstraction

Mais mon sentiment c'est qu'a force d'abstraction pour le plaisir on finit pas avoir du mal a retrouver ses jeunes !