ObservableCollection <> frente a List <>


78

Tengo muchas entidades anidadas List<>en cada una.

Por ejemplo, tengo lo BaseEntityque tiene List<ColumnEntity>. ColumnEntityclase tiene List<Info>y así sucesivamente.

Estamos trabajando con una interfaz de usuario de WPF y necesitamos realizar un seguimiento de todos los cambios en cada lista de BaseEntity. Se implementa creando una instancia new ObservableCollectionbasada en la lista necesaria y con un enlace a eso ObservableCollection.

¿Cuáles son los pros y los contras cambiando todos estos anidados Listsa ObservableCollections? Entonces, ¿podemos rastrear todos los cambios en BaseEntitysí mismo sin reasignar cada lista BaseEntitya un límite modificado ObservableCollection?

Suponiendo que los métodos específicos de Listnunca se utilizan.

Respuestas:


89

Pregunta interesante, considerando que tanto List como ObservableCollectionimplementar IList<T>no hay mucha diferencia allí, ObservableCollectiontambién implementa la INotifyCollectionChangedinterfaz, lo que permite que WPF se vincule a ella.

Una de las principales diferencias es que ObservableCollectionno tiene AddRangemétodo, lo que podría tener algunas implicaciones.

Además, no lo usaría ObservableCollectionpara lugares donde sé que no me vincularía, por esta razón es importante repasar su diseño y asegurarse de que está tomando el enfoque correcto al separar las capas de interés.

En cuanto a las diferencias entre Collection<T>y List<T>puedes echar un vistazo aquí Listas genéricas vs Colección


2
Arreglé el enlace y se aprobó el cambio.
Joe

36

Depende exactamente de lo que quieras decir con esto:

Necesitamos rastrear todos los cambios en cada Lista de BaseEntity

¿Sería suficiente realizar un seguimiento de los cambios en los objetos que ya están en la lista? ¿O necesita saber cuándo los objetos se eliminan, se agregan o cambian de posición dentro de la lista?

Si una lista contendrá los mismos elementos durante toda su vida, pero los objetos individuales dentro de esa lista cambiarán, entonces es suficiente que solo los objetos generen notificaciones de cambio (generalmente a través INotifyPropertyChanged) y List<T>es suficiente. Pero si la lista contendrá diferentes objetos de vez en cuando, o si el orden cambia, entonces debería usar ObservableCollection<T>.

Entonces, si bien las diferencias pueden ser interesantes (y un póster anterior ya las ha cubierto), generalmente no tendrá muchas opciones, o las necesita ObservableCollection<T>o no.


3
Bien pensado. +1
Subby el

12

Lista representa una lista fuertemente tipada de objetos a los que se puede acceder por índice. Proporciona métodos para buscar, ordenar y manipular listas. La clase List es el equivalente genérico de la clase ArrayList. Implementa la interfaz genérica IList usando una matriz cuyo tamaño se incrementa dinámicamente según sea necesario.

ObservableCollection es una recopilación de datos dinámicos genéricos que utiliza una interfaz "INotifyCollectionChanged" para proporcionar notificaciones cuando se agregan, eliminan elementos o cuando se actualiza toda la colección.

Lea más sobre esto en este enlace: http://www.codeproject.com/Articles/42536/List-vs-ObservableCollection-vs-INotifyPropertyCha


10

Una diferencia más importante es que puede acceder a ObservableCollection solo desde el hilo en el que se creó, donde se puede acceder a una lista desde cualquier hilo.


1
Falso. Puede acceder a ambos desde cualquier hilo. Pero cuando ObservableCollection está vinculado a ItemsControl, si se activa un cambio desde un hilo no gráfico, modificará un objeto gráfico desde un hilo no gráfico. Y está prohibido -> excepción
Emmanuel DURIN

6

No veo ningún problema con eso, aparte de una sobrecarga de rendimiento muy marginal.

Tenga en cuenta que si modifica las Listas internas directamente, no se le notificará sobre los cambios. Además, si se modifican los objetos que están contenidos en ObservableCollection, no se le notificará. La notificación se produce solo si se agregan, reemplazan, eliminan o mueven elementos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.