ArrayList versus una matriz de objetos versus Colección de T

Question

Tengo una clase Customer (con propiedades típicas del cliente) y necesito pasar, y databind, un "fragmento" de instancias Customer. Actualmente estoy usando una matriz de Customer, pero también he usado Collection de T (y List de T antes de saber Collection de T). Me gustaría la forma más delgada de pasar este pedazo con C# y .NET 3.5.

Actualmente, la matriz de Customer está funcionando bien para mí. La información se une bien y parece ser tan liviana como se pone. No necesito las cosas List de T ofertas y Collection de T todavía parece exagerado. La matriz requiere que sepa por adelantado cuántos Customer s estoy agregando al fragmento, pero siempre lo sé de antemano (filas dadas en una página, por ejemplo).

¿Echo de menos algo fundamental o es el conjunto de Customer OK? ¿Hay una compensación que me falta?

Además, asumo que Collection de T hace obsoleto el viejo ArrayList. ¿Estoy allí?

Answer 1

Nadie ha mencionado el consejo Directrices Marco: Don't use List<T> in public API's:

No se recomienda el uso de la lista de API públicas por dos razones.

• List<T> no está diseñado para extenderse. es decir, no puede anular ningún miembro . Esto significa que, por ejemplo, un objeto regresar List<T> de una propiedad no será capaz de ser notificado cuando se modifica la colección. Collection<T> le permite anular Miembro protegido de SetItem para obtener "notificado" cuando se agregan nuevos artículos o se cambia un elemento existente.

• Lista tiene un montón de miembros que no son relevantes en muchos escenarios. Nosotros decimos que List<T> está demasiado "ocupado" para los modelos de objetos públicos . Imagine Propiedad ListView.Items que devuelve List<T> con toda su riqueza. Ahora, mira el tipo de devolución real ListView.Items ; él es manera más simple y similar a Collection<T> o ReadOnlyCollection<T>

Además, si su objetivo es bidireccional enlace de datos, echar un vistazo a BindingList<T> (con la salvedad de que no se puede ordenar 'fuera de la caja '!)

Answer 2

Sí, Collection<T> (o más comúnmente) hace ArrayList bastante obsoleto. En particular, creo que ArrayList ni siquiera es compatible con Silverlight 2.

Las matrices están bien en algunos casos, pero deben ser considered somewhat harmful; tienen varias desventajas. (Están en el corazón de la implementación de la mayoría de las colecciones, por supuesto ...) Entraría en más detalles, pero Eric Lippert lo hace mucho mejor de lo que pude en el artículo al que hace referencia el enlace. Lo resumiría aquí, pero eso es bastante difícil de hacer. Realmente vale la pena solo leer la publicación completa.

Answer 3

general, debe 'pasar alrededor' IEnumerable <T> o ICollection <T> (dependiendo de si tiene sentido para su consumo a añadir elementos).

Answer 4

Voy a presentar un argumento disidente tanto para Jon como para Eric Lippert) lo que significa que ¡de hecho deberías estar muy cansado de mi respuesta!).

El corazón de los argumentos de Eric Lippert contra las matrices es que los contenidos son inmutables, mientras que la estructura de datos en sí no lo es. Con respecto a devolverlos de los métodos, los contenidos de una lista son tan mutables. De hecho, debido a que puede agregar o quitar elementos de una lista, yo diría que esto hace que el valor de retorno sea más mutable que una matriz.

La otra razón por la que soy aficionado a Arrays es porque hace un tiempo tuve una pequeña sección de código de rendimiento crítico, por lo que comparaté las características de rendimiento de los dos, y los arreglos volaron listas fuera del agua. Ahora, permítanme advertir esto diciendo que fue una prueba limitada de cómo iba a usarlos en una situación específica, y va en contra de lo que yo entiendo de ambos, pero los números fueron muy diferentes.

De todos modos, escuche a Jon y Eric =), y estoy de acuerdo en que la lista casi siempre tiene más sentido.

Answer 5

Estoy de acuerdo con Alun, con una adición. Si desea abordar el valor de retorno por el subíndice myArray [n], utilice un IList.

Una matriz inherentemente apoya IList (así como IEnumerable y ICollection, para esa materia). Entonces, si pasa por la interfaz, puede usar la matriz como su estructura de datos subyacente. De esta manera, los métodos que está de paso en la matriz no tiene que "saber" que la estructura de datos subyacente es una matriz:

 public void Test() 
{ 
    IList<Item> test = MyMethod(); 
} 

public IList<Item> MyMethod() 
{ 
    Item[] items = new Item[] {new Item()}; 
    return items; 
} 

Answer 6

Si usted tiene una lista inmutable de los clientes, que es ... su lista de clientes no cambiará, es relativamente pequeña, y siempre se repetirá sobre ella de principio a fin y no es necesario agregarla a la lista o eliminarla, entonces una matriz probablemente esté bien.

Si no está seguro, sin embargo, su mejor apuesta es una colección de algún tipo. La colección que elija depende de las operaciones que desea realizar en ella. Las colecciones tienen que ver con inserciones, manipulaciones, búsquedas y eliminaciones. Si realiza frecuentes búsquedas frecuentes de un elemento determinado, entonces un diccionario puede ser el mejor. Si necesita ordenar los datos, quizás una SortedList funcione mejor.

yo no me preocuparía por "ligera", a menos que estés hablando de una enorme cantidad de elementos, e incluso entonces las ventajas de O (1) operaciones de búsqueda son mayores que los costos de los recursos.

Cuando "pasa" una colección, solo está pasando una referencia, que es básicamente un puntero. Por lo tanto, no hay diferencia de rendimiento entre pasar una colección y una matriz.