Avantages / inconvénients de List <T> vs BindingList <T>

Quelqu'un peut-il décrire la différence entre les deux pour mon projet.

Actuellement, j'ai un List<MyClass>et défini le BindingSource sur cela et un DataGridView sur le BindingSource.

J'ai implémenté IEditableObjectdonc lorsque CancelEdit est appelé, je rétablis mon objet à ce qu'il était avec unMemberwise.Clone()

Le changement de ma liste en une liste de liaison résoudra-t-il tout cela et quels sont les avantages de l'utilisation d'une liste de liaison?

— Jon
source

123

A List<>est simplement un tableau de redimensionnement automatique, d'éléments d'un type donné, avec quelques fonctions d'assistance (par exemple: sort). Ce ne sont que les données, et vous allez probablement les utiliser pour exécuter des opérations sur un ensemble d'objets de votre modèle.

A BindingList<>est un wrapper autour d'une liste typée ou d'une collection, qui implémente l' IBindingListinterface. C'est l'une des interfaces standard qui prennent en charge la liaison de données bidirectionnelle. Cela fonctionne en implémentant l' ListChangedévénement, qui est déclenché lorsque vous ajoutez, supprimez ou définissez des éléments. Les contrôles liés écoutent cet événement afin de savoir quand actualiser leur affichage.

Lorsque vous définissez DataSource d'un BindingSource sur a List<>, il crée en interne un BindingList<>pour encapsuler votre liste. Vous voudrez peut-être pré-envelopper votre liste avec un BindingList<>vous-même si vous souhaitez y accéder en dehors de BindingSource, mais sinon, c'est la même chose. Vous pouvez également hériter de BindingList<>pour implémenter un comportement spécial lors de la modification d'éléments.

IEditableObjectest géré par le BindingSource. Il appellera BeginEdit sur n'importe quel objet d'implémentation lorsque vous modifiez les données dans n'importe quel contrôle lié. Vous pouvez ensuite appeler EndEdit / CancelEdit sur le BindingSource et il le transmettra à votre objet. Le passage à une ligne différente appellera également EndEdit.

— Alex J
source

Actuellement, avec mon approche List <T>, appeler CancelEdit ne retournera pas l'élément en cours de modification à son état d'origine, d'où la raison pour laquelle j'utilise Clone (). Êtes-vous en train de dire qu'une liste de liens gérera cela pour moi?

— Jon

Non, une BindingList n'a rien à voir avec cette fonctionnalité. Le BindingSource appelle simplement CancelEdit sur l'objet actuel quel que soit le type de liste sous-jacente. Il n'y a rien dans le framework qui implémente automatiquement la gestion des versions d'objets pour les objets simples. Vous pouvez utiliser DataTables / DataRows, qui conservent une copie originale des données à cette seule fin.

— Alex J

Vous dites que les contrôles doivent savoir quand la liste change, pouvez-vous expliquer davantage? J'ai un formulaire avec un datagridview, puis un autre formulaire avec des données remplies. Dois-je me préoccuper de ce que vous dites à ce sujet?

— Jon

Par exemple, le DataGrid a besoin de savoir quand des éléments sont ajoutés à votre liste afin d'ajouter une nouvelle ligne. Pour cela, il utilise l'événement ListChanged du BindingList. Si vous liez la grille directement à un List <T>, vous n'auriez pas l'événement, et la grille ne pourrait pas savoir quand vous avez changé la liste. Vous n'avez pas à vous en soucier dans votre scénario car le BindingSource encapsule le List <T> dans une BindingList pour vous. Tant que vous travaillez avec BindingSource et non avec la liste elle-même, les contrôles resteront synchronisés.

— Alex J

Existe-t-il une solution de contournement pour utiliser BindingList à WPF UI (la manière mvvm)? Puis-je envelopper la liste de liaison dans une collection observable?

— Lance

Une BindingList autorise la liaison de données bidirectionnelle à l'aide d'événements, une liste ne déclenche pas d'événements lorsque sa collection change.

Je ne pense pas que cela résoudra votre problème particulier.

— Gerrie Schenck
source