¿Por qué debería usar List <T> sobre IEnumerable <T>?

En mi aplicación web ASP.net MVC4 utilizo IEnumerables, tratando de seguir el mantra para programar en la interfaz, no la implementación.

Return IEnumerable(Of Student)

vs

Return New List(Of Student)

La gente me dice que use List y no IEnumerable, porque las listas obligan a que se ejecute la consulta y IEumerable no.

¿Es esta realmente la mejor práctica? ¿Hay alguna alternativa? Me siento extraño usando objetos concretos donde podría usarse una interfaz. ¿Está justificado mi extraño sentimiento?

Hay momentos en los que hacer ToList()consultas en su linq puede ser importante para garantizar que sus consultas se ejecuten en el momento y en el orden que espera. Sin embargo, esos escenarios son raros y no hay nada de qué preocuparse demasiado hasta que realmente se encuentren con ellos.

Para resumir, use en IEnumerablecualquier momento que solo necesite iteración, use IListcuando necesite indexar directamente y necesite una matriz de tamaño dinámico (si necesita indexar en una matriz de tamaño fijo, simplemente use una matriz estándar).

En cuanto al tiempo de ejecución, siempre puede usar una lista como IEnumerablevariable, así que siéntase libre de devolver un IEnumerablehaciendo un .ToList();, o pasar un parámetro como un IEnumerableejecutando .ToList()el IEnumerablepara forzar la ejecución en ese momento. Solo tenga cuidado de que cada vez que fuerce la ejecución con .ToList()usted no se aferre a la IEnumerablevariable a la que acaba de hacer eso y la ejecute nuevamente, o de lo contrario terminará duplicando las iteraciones en su consulta LINQ innecesariamente.

En lo que respecta a MVC, realmente no hay nada especial que destacar aquí. Va a seguir las mismas reglas de tiempo de ejecución que el resto de .NET, creo que podrías tener a alguien que fue mordido por la confusión causada por la semántica de ejecución retrasada en el pasado y culpó a MVC de decirte que esto está de alguna manera relacionado, pero está no. La semántica de ejecución demorada confunde a todos al principio (e incluso por un buen tiempo después; pueden ser un poco complicados). Sin embargo, una vez más, no se preocupe por eso hasta que realmente se preocupe por asegurarse de que una consulta LINQ no se ejecute dos veces o requiera que se ejecute en un cierto orden en relación con otro código, en ese momento asigne su variable a sí mismo. ToList () para forzar la ejecución y estarás bien.

Hay dos problemas

IENumerable<Data> query = MyQuery();

//Later
foreach (Data item in query) {
  //Process data
}

En el momento en que se alcanza el ciclo "Datos de proceso", la consulta ya no es válida. Por ejemplo, si la consulta se ejecuta en un DataContext que ya se ha eliminado, su código arrojará una excepción. Este tipo de cosas se vuelve muy confuso cuando procesas una consulta en un contexto diferente al que la creaste.

Un problema secundario es que su conexión no se liberará hasta que se complete el ciclo "Datos de proceso". Esto es solo un problema si "Datos de proceso" es complejo. Esto se menciona en http://msdn.microsoft.com/en-us/library/bb386929.aspx :

P. ¿Cuánto tiempo permanece abierta la conexión de mi base de datos?

A. Una conexión generalmente permanece abierta hasta que consume los resultados de la consulta. Si espera tomarse el tiempo para procesar todos los resultados y no se opone al almacenamiento en caché de los resultados, aplique ToList a la consulta. En escenarios comunes donde cada objeto se procesa solo una vez, el modelo de transmisión es superior tanto en DataReader como en LINQ to SQL.

Por lo tanto, estos problemas son la razón por la que se le recomienda asegurarse de que la consulta se ejecute realmente, por ejemplo, llamando ToList(). Sin embargo, como Jimmy sugiere, no hay nada que le impida devolver su Lista como IEnumerable.

Como regla general, recomiendo evitar iterar sobre un IEnumerable más de una vez. Suponiendo que los consumidores de su código sigan esta regla, no considero una preocupación que alguien pueda acceder a la base de datos dos veces ejecutando la consulta dos veces.

Otro beneficio de enumerar IEnumerabletemprano es que las excepciones se lanzarán en la ubicación adecuada. Esto ayuda a la depuración.

Por ejemplo, si tiene una excepción de punto muerto dentro de una de sus vistas de Razor, no sería tan claro como si la excepción ocurriera durante uno de sus métodos de acceso a datos.