Força Linq para não execução de atraso

Question

Na verdade, esta é a mesma pergunta que este post:

Como posso ter certeza de minhas consultas LINQ executar quando chamado no meu DAL, não de uma forma retardada?

Mas desde que ele não explicou por ele queria, a questão parece ter sido preterido um pouco. Aqui está o meu problema semelhante-mas-melhor-explicou:

Eu tenho um punhado de tópicos em dois tipos (ignorando tópicos UI por um momento). Há uma "recolha de dados" tipo de rosca, e um "cálculo" tipo de rosca. Os tópicos de coleta de dados são lentas. Há um um pouco de dados a ser peneirado através de uma variedade de lugares. Os tópicos de computação são relativamente rápido. O modelo de design até este ponto é para enviar dados de coleta de tópicos off para encontrar dados, e quando eles estão de passagem completa os dados acima para a computação.

Quando eu codificado meus dados reunidos em Linq acabei içar um pouco dessa lentidão volta para o meu computação tópicos . Existem agora elementos de dados que não estão sendo resolvidos completamente até que eles são usados ??durante a computação -. E isso é um problema

Eu gostaria de forçar Linq para concluir seu trabalho em um determinado momento (fim da declaração? Final de método? "Por favor terminar, caramba" chamada de método) para que eu sei que não estou pagando por isso mais tarde . Adicionando ".ToList ()" ao final do Linq é 1. desajeitado, e 2. Parece que algo de boxe que está prestes a ser unboxed em outro segmento momentaneamente qualquer maneira.

Answer 1

Você não seria nada de boxe -. Você estaria buffer os resultados

Usando ToList() é basicamente o caminho a percorrer se você realmente deseja que os dados. A menos que você está pronto para usar os dados imediatamente, ele tem que ser tamponado em algum lugar , não é? A lista é apenas uma maneira conveniente de fazer isso.

A alternativa é fazer o processamento em seguida, e lá também - utilizar os dados como você produzi-lo, ansiosamente. Eu não chegou a seguir o lado diferentes tópicos de coisa, então não é claro para mim se que iria ajudá-lo, mas esses são, basicamente, as opções disponíveis para você, tanto quanto eu posso ver.

Esta é realmente um pouco explícito na sua descrição:

O modelo de design até este ponto é Para enviar dados de coleta de tópicos off para encontrar dados, e quando eles estão completos passar os dados para a computação.

Chamando ToList() basicamente muda o que você retornar de "uma consulta que pode buscar os dados quando solicitado a" para "os dados em si, em buffer em uma lista".

Answer 2

Você pode explicar mais porque .ToList não é aceitável? Você mencionou boxing e unboxing mas esses são completamente temas não relacionados.

Parte de forçar uma consulta LINQ para completar on exija demanda armazenar os resultados. Caso contrário, a fim de ver os resultados, novamente, você teria que repprocess a consulta. .ToList eficientemente alcança este armazenando os elementos em um List<T>.

É possível armazenar os elementos em praticamente qualquer outra estrutura de dados estilo coleção com vários trade-offs que podem atender às suas necessidades melhor.

Answer 3

Há uma propriedade LoadOptions na classe DataContext que poderiam ajudá-lo a buscar os dados mais ansiosamente.

Outra coisa que você poderia usar alguns ToList() colocado inteligente é.

Answer 4

Eu sei que esta discussão é antiga ... de qualquer maneira, engraçado ninguém mencionou .ToLast () ainda. Eu estou fazendo algo onde LINQ não é muito mais do que um foreach glorificado dirigir alguns efeitos colaterais onde eu realmente não se preocupam com o resultado da consulta ... então eu não queria alocar qualquer memória mais falso do que o necessário.