ObservableCollection <> порівняно зі списком <>


78

У мене багато сутностей із вкладеними List<>в кожну.

Наприклад, я маю, BaseEntityщо має List<ColumnEntity>. ColumnEntityклас має List<Info>тощо.

Ми працюємо з інтерфейсом користувача WPF , і нам потрібно відстежувати всі зміни у кожному списку BaseEntity. Він реалізується шляхом створення екземпляра на new ObservableCollectionоснові необхідного списку та з прив'язкою до нього ObservableCollection.

Які плюси і мінуси змінюються всі ці вкладені Listsв ObservableCollections? Тож ми можемо відстежувати всі зміни BaseEntityсамі по собі, не перепризначаючи кожен список BaseEntityмодифікованих прив’язаних ObservableCollection?

Припускаючи, що методи, характерні для List, ніколи не використовуються.

Відповіді:


89

Цікаве питання, враховуючи, що як у списку, так і в ObservableCollectionреалізації IList<T>немає особливої ​​різниці, ObservableCollectionтакож реалізований INotifyCollectionChangedінтерфейс, який дозволяє WPF прив'язуватися до нього.

Однією з головних відмінностей є те, що ObservableCollectionнемає AddRangeметоду, що може мати певні наслідки.

Крім того, я б не використовував ObservableCollectionмісця, де я знаю, що не буду до них прив’язуватись, з цієї причини важливо переглянути ваш дизайн і переконатися, що ви приймаєте правильний підхід до розділення шарів, що викликають занепокоєння.

Що стосується відмінностей між Collection<T>і List<T>ви можете подивитися тут Загальні списки проти колекції


2
Я зафіксував посилання, і зміну було схвалено.
Джо

36

Це залежить від того, що саме ви маєте на увазі під цим:

нам потрібно відстежувати всі зміни у кожному списку BaseEntity

Чи було б достатньо для відстеження змін об’єктів, які вже є у списку? Або вам потрібно знати, коли об’єкти видаляються з / додаються / змінюють позиції у списку?

Якщо список буде містити одні й ті самі елементи протягом усього життя, але окремі об'єкти в цьому списку будуть змінюватися, тоді достатньо лише об'єктам підняти сповіщення про зміни (як правило, через INotifyPropertyChanged) і List<T>цього достатньо. Але якщо список час від часу буде містити різні об'єкти або якщо порядок змінюється, то вам слід скористатися цимObservableCollection<T> .

Тож, хоча відмінності можуть бути цікавими (а попередній плакат їх уже охоплював), як правило, у вас не буде такого великого вибору - або вам потрібно, ObservableCollection<T>або ні.


3
Гарно продуманий. +1
Саббі

12

Список представляє сильно набраний список об'єктів, до яких можна отримати доступ за допомогою індексу. Він надає методи пошуку, сортування та керування списками. Клас List є загальним еквівалентом класу ArrayList. Він реалізує загальний інтерфейс IList, використовуючи масив, розмір якого динамічно збільшується за потреби.

ObservableCollection - це загальний динамічний збір даних, який використовує інтерфейс "INotifyCollectionChanged", щоб надавати сповіщення про додавання, вилучення елементів або оновлення всієї колекції.

Детальніше про це читайте за цим посиланням: http://www.codeproject.com/Articles/42536/List-vs-ObservableCollection-vs-INotifyPropertyCha


10

Ще одна важлива відмінність полягає в тому, що ви можете отримати доступ до ObservableCollection лише з потоку, у якому він був створений, де як список можна отримати доступ з будь-якого потоку.


1
Неправдиві. Ви можете отримати доступ до обох з будь-якого потоку. Але коли ObservableCollection прив’язано до ItemsControl, якщо зміна ініціюється з не графічного потоку, це змінить графічний об’єкт із неграфічного потоку. І це заборонено -> виняток
Еммануель ДУРІН

6

Я не бачу в цьому жодної проблеми, окрім дуже незначних накладних витрат.

Зверніть увагу, що якщо ви змінюєте внутрішні Списки безпосередньо, вас не повідомляють про зміни. Також якщо об'єкти, що містяться в ObservableCollection, змінені, ви не отримуєте повідомлення. Повідомлення відбувається лише в тому випадку, якщо елементи додаються, замінюються, видаляються або переміщуються.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.