Différence entre ObservableCollection et BindingList

Question

Je souhaite connaître la différence entre ObservableCollection et BindingList, car j'ai déjà utilisé les deux pour notifier toute modification de l'ajout/suppression dans Source, mais je ne sais pas quand préférer l'une ou l'autre. .

Pourquoi devrais-je choisir l'un des suivants sur l'autre?

ObservableCollection<Employee> lstEmp = new ObservableCollection<Employee>();

ou

BindingList<Employee> lstEmp = new BindingList<Employee>();

Eilistraee · Accepted Answer

Un ObservableCollection peut être mis à jour à partir de l'interface utilisateur exactement comme n'importe quelle collection. La vraie différence est plutôt simple:

ObservableCollection<T> implémente INotifyCollectionChanged qui fournit une notification lorsque la collection est modifiée (vous l'avez deviné ^^). Il permet au moteur de liaison de mettre à jour l'interface utilisateur lorsque le ObservableCollection est mis à jour.

Toutefois, BindingList<T> implémente IBindingList.

IBindingList fournit une notification sur les modifications de la collection, mais pas seulement. Il fournit tout un ensemble de fonctionnalités que l’UI peut utiliser pour fournir bien plus que la mise à jour de l’UI en fonction des modifications, telles que:

Tri
Recherche
Ajouter via la fabrique (fonction membre AddNew).
Liste en lecture seule (propriété CanEdit)

Toutes ces fonctionnalités ne sont pas disponibles dans ObservableCollection<T>

Une autre différence est que BindingList relaie les notifications de changement d'élément lorsque ses éléments implémentent INotifyPropertyChanged. Si un élément déclenche un événement PropertyChanged, le BindingList le recevra et déclenchera un ListChangedEvent avec ListChangedType.ItemChanged et OldIndex=NewIndex _ (si un élément a été remplacé, OldIndex=-1). ObservableCollection ne transmet pas les notifications d'élément.

Notez que dans Silverlight, BindingList n’est pas disponible en option: vous pouvez cependant utiliser ObservableCollections et ICollectionView (et IPagedCollectionView si je me souviens bien).

Dean Chalk · Answer

La différence pratique est que BindingList est pour WinForms et ObservableCollection est pour WPF.

Du point de vue de WPF, BindingList n’est pas correctement pris en charge et vous ne l’utiliseriez jamais vraiment dans un projet WPF à moins que vous n’ayez vraiment à le faire.

Kylo Ren · Answer

One More grosse différence entre ObservableCollection et BindingList est pratique et peut constituer un facteur de décision de l'enchère sur le sujet. :

BindingList Gestionnaire de modification de liste:

ObservableCollection Modification de la collection:

Résumé de ce qui précède: Si une propriété d'un élément est modifiée dans BindingList, l'événement ListChanged vous en donnera une complète les détails de la propriété (dans PropertyDescriptor) et ObservableCollection ne vous donneront pas cela. En fait, ObservableCollection ne déclenchera pas d'événement de modification pour une propriété modifiée dans un élément.

La conclusion ci-dessus concerne INotifyPropertyChanged implémenté dans les classes de modèle. Par défaut, none déclenche l'événement modifié si une propriété est modifiée dans un élément.

Gy&#246;rgy Kőszeg · Answer

Les différences les plus importantes, telles que les fonctionnalités et les notifications de modification concernant les éléments contenus, sont déjà mentionnées dans la réponse acceptée, mais il en existe d'autres, qui méritent également d'être mentionnées:

Performance

Lorsque AddNew est appelé, BindingList<T> recherche l'élément ajouté par une recherche IndexOf. Et si T implémente INotifyPropertyChanged, l'index d'un élément modifié est également recherché par IndexOf (bien qu'il n'y ait pas de nouvelle recherche tant que le même élément change de façon répétée). Si vous stockez des milliers d'éléments dans la collection, alors ObservableCollection<T> (ou une implémentation personnalisée de IBindingList avec O(1) coût de la recherche)] peut être préférable.

Complétude

L'interface IBindingList est énorme (peut-être pas la conception la plus propre) et permet aux développeurs de mettre en œuvre un sous-ensemble de ses fonctionnalités. Par exemple, les propriétés AllowNew, SupportsSorting et SupportsSearching indiquent si les méthodes AddNew, ApplySort et Find peuvent être utilisé, respectivement. Cela surprend souvent les gens qui BindingList<T> lui-même ne supporte pas le tri. En fait, il fournit des méthodes virtuelles permettant aux classes dérivées d'ajouter les fonctionnalités manquantes. La classe DataView est un exemple d'implémentation complète de IBindingList; Cependant, ce n'est pas pour les collections tapées en premier lieu. Et la classe BindingSource dans WinForms est un exemple hybride: elle prend en charge le tri si elle englobe une autre implémentation IBindingList, qui prend en charge le tri.
ObservableCollection<T> est déjà une implémentation complète de l'interface INotifyCollectionChanged (qui n'a qu'un seul événement). Il a aussi des membres virtuels mais ObservableCollection<T> est généralement dérivé pour la même raison que sa base Collection<T> class: pour personnaliser l'ajout/la suppression d'éléments (par exemple, dans une collection de modèles de données) plutôt que d'ajuster les fonctionnalités de reliure.

Copie vs. emballage

Tous les deux ObservableCollection<T> et BindingList<T> ont un constructeur qui accepte une liste déjà existante. Bien qu'ils se comportent différemment lorsqu'ils sont instanciés par une autre collection:

BindingList<T> agit comme un observable pour la liste fournie et les modifications effectuées sur le BindingList<T> sera également reflété sur la collection sous-jacente.
ObservableCollection<T> d'autre part passe un nouveau List<T> instance à la base Collection<T> constructeur et copie les éléments de la collection originale dans cette nouvelle liste. Bien sûr, si T est un type de référence, les modifications apportées aux éléments seront visibles depuis la collection d'origine, mais la collection elle-même ne sera pas mise à jour.