LINQ forzar a no retrasar la ejecución

Question

De hecho, esta es la misma pregunta que este mensaje:

¿Cómo puedo asegurarme de que mis consultas LINQ ejecutan cuando se le llama en mi DAL, no de manera retardada?

Pero ya que él no ha explicado ¿Por qué lo quería, la cuestión parece haber sido pasado por alto un poco. Aquí está mi problema similar, pero--mejor explicó:

Tengo un puñado de hilos en dos tipos de interfaz de usuario (haciendo caso omiso de las discusiones por un momento). Hay un tipo de rosca "recopilación de datos", y un tipo de rosca "computación". Los hilos de recolección de datos son lentos. Hay un un poco de datos que son tamizados a través de una variedad de lugares. Los hilos de cálculo son comparativamente rápido. El modelo de diseño hasta este punto es el envío de hilos de recopilación de datos a buscar los datos, y cuando están pasada completa los datos para el cálculo.

Cuando codifiqué mi recopilación de datos en LINQ terminé de elevación un poco de esa lentitud de nuevo en mis hilos de cálculo . En la actualidad hay elementos de datos que no están siendo resueltos por completo hasta que son utilizados durante el cálculo - y eso es un problema

.

Me gustaría forzar LINQ para terminar su trabajo en un momento dado (al final de la declaración? Final del método? "Por favor terminar, maldita sea" llamada de método) de modo que sé que no estoy pagando por ello más adelante . Añadiendo ".ToList ()" al final de la LINQ es 1. incómoda, y 2. se siente como el boxeo algo que está a punto de ser sacó de la caja en otro hilo momentáneamente de todos modos.

Answer 1

Usted no sería nada de boxeo -. Estarías buffering los resultados

El uso de ToList() es básicamente el camino a seguir si usted quiere realmente los datos. A menos que esté listo para utilizar los datos de forma inmediata, que tiene que ser amortiguada alguna parte , no es así? Una lista es sólo una manera conveniente de hacer eso.

La alternativa es hacer el procesamiento a continuación, y allí también - utilizar los datos a medida que se producen, con impaciencia. Yo no comprendo muy bien el lado diferentes hilos de cosas, así que no es claro si eso ayudará, pero esos son básicamente las opciones disponibles para usted por lo que yo puedo ver.

Esto es en realidad algo explícito en su descripción:

  

El modelo de diseño hasta este punto es   enviar hilos de recopilación de datos fuera de   encontrar datos, y cuando están completa   pasar los datos para el cálculo.

Llamando <=> básicamente cambia lo regrese de "una consulta que puede recuperar los datos cuando se le preguntó a" a "los datos en sí, tamponada en una lista".

Answer 2

¿Puede explicar por qué más .ToList no es aceptable? Usted ha mencionado el boxeo y unboxing pero esos son completamente temas no relacionados.

Parte de forzar una consulta LINQ para completar la demanda hace necesario almacenar los resultados. De lo contrario, con el fin de ver los resultados de nuevo, habría que repprocess la consulta. .ToList logra eficientemente esto almacenando los elementos en un List<T>.

Es posible almacenar los elementos en prácticamente cualquier otra estructura de datos estilo colección con diferentes compensaciones que puedan adaptarse mejor a sus necesidades.

Answer 3

Hay una LoadOptions propiedad en el DataContext clase que podría ayudarle a obtener los datos con más ganas.

Otra cosa que podría utilizar algunos inteligente colocado ToList() 's.

Answer 4

Sé que este hilo es viejo ... de todos modos, divertido, nadie mencionó .ToLast () todavía. Estoy haciendo algo donde LINQ no es mucho más que un foreach glorificado conducir algunos efectos secundarios, donde realmente no se preocupan por el resultado de la consulta ... así que no quería asignar cualquier memoria falsa más de lo necesario.