De retour IEnumerable<T> vs IQueryable<T>

Haut réponse est bonne, mais il ne mentionne pas l'expression d'arbres qui expliquent "comment" les deux interfaces différentes. Fondamentalement, il existe deux ensembles identiques de extensions LINQ. Where(), Sum(), Count(), FirstOrDefault(), etc ont tous deux versions: l'une qui accepte des fonctions et celui qui accepte d'expressions.

• La IEnumerable version signature est: Where(Func<Customer, bool> predicate)

• La IQueryable version signature est: Where(Expression<Func<Customer, bool>> predicate)

Vous avez probablement été à l'aide de ces deux sans s'en rendre compte parce que les deux sont appelées à l'aide identiques syntaxe:

par exemple Where(x => x.City == "<City>") fonctionne sur les deux IEnumerable et IQueryable

• Lors de l'utilisation de Where() sur un IEnumerable la collecte, le compilateur passe d'une fonction compilée pour Where()

• Lors de l'utilisation de Where() sur un IQueryable la collecte, le compilateur passe une arborescence d'expression à Where(). Une arborescence d'expression est comme le reflet du système, mais pour le code. Le compilateur convertit votre code en une structure de données qui décrit ce que votre code dans un format facile à digérer.

Pourquoi s'embêter avec cette expression de l'arbre chose? Je veux juste Where() pour filtrer mes données.
La raison principale est que les deux objectifs EF et Linq2SQL Orm peut convertir des arbres d'expression directement dans SQL où votre code s'exécute beaucoup plus rapidement.

Oh, qui sonne comme un spectacle gratuit boost, dois-je utiliser AsQueryable() toute la place dans ce cas?
Non, IQueryable n'est utile que si les données sous-jacentes fournisseur peut faire quelque chose avec elle. La conversion de quelque chose comme un List à IQueryable ne vous sera d'aucun profit.

OriginalL'auteur Jacob

Les deux vous donnera l'exécution différée, oui.

Que pour ce qui est préférée à une autre, cela dépend de votre source de données sous-jacente est.

Retour d'un IEnumerable automatiquement la force de l'exécution pour utiliser LINQ to Objects pour interroger votre collection.

Retour d'un IQueryable (qui implémente IEnumerable, par la voie) fournit la fonctionnalité supplémentaire pour traduire votre requête dans quelque chose qui pourrait mieux fonctionner sur la source sous-jacent (LINQ to SQL, LINQ to XML, etc.).

OriginalL'auteur Justin Niessner

Beaucoup a été dit précédemment, mais d'un retour aux sources, de manière plus technique:

1. IEnumerable est une collection d'objets en mémoire que vous pouvez énumérer - en mémoire une séquence qui permet d'itérer (il est facile pour l'intérieur de foreach boucle, si vous pouvez aller avec IEnumerator seulement). Ils résident dans la mémoire.
2. IQueryable est une expression de l'arbre qui sera traduit en quelque chose d'autre à un point avec possibilité d'énumérer sur le résultat final. Je suppose que c'est ce qui confond la plupart des gens.

Il est évident qu'ils ont des connotations différentes.

IQueryable représente une expression de l'arbre (une requête, tout simplement) qui sera traduit en quelque chose d'autre par la requête sous-jacente fournisseur dès que les Api sont appelés, comme LINQ fonctions d'agrégation (Sum, Count, etc.) ou ToList[Tableau, Dictionnaire,...]. Et IQueryable objets également de mettre en œuvre IEnumerable, IEnumerable<T> de sorte que si elles représentent une requête le résultat de cette requête pourrait être réitéré. Cela signifie IQueryable n'ont pas à être les requêtes. Le bon terme, c'est qu'ils sont des arbres d'expression.

Maintenant comment ces expressions sont exécutés et qu'ils se tournent vers l'est tous, jusqu'à ce qu'on appelle fournisseurs de requêtes (expression exécuteurs nous pouvons penser à eux).

Dans le Entity Framework monde (qui est mystique de données sous-jacente source prestataire ou fournisseur de requêtes) IQueryable expressions sont traduites en natif T-SQL requêtes. Nhibernate fait des choses similaires avec eux. Vous pouvez écrire votre propre en suivant les concepts assez bien décrite dans LINQ: la Construction d'un IQueryable Fournisseur lien, par exemple, et vous pourriez être personnalisé à l'interrogation de l'API pour votre magasin de produits fournisseur de service.

Donc, fondamentalement, IQueryable objets se construit tout au long chemin jusqu'à nous libérer explicitement eux et de dire que le système de réécriture dans SQL ou autre et d'envoyer la chaîne d'exécution pour la poursuite du traitement.

Comme si de différés exécution, il est un LINQ fonctionnalité pour tenir jusqu'à l'expression de l'arbre régime de la mémoire et de l'envoyer dans l'exécution sur demande uniquement, lorsque certaines Api sont appelés à l'encontre de la séquence (le même Comte, ToList, etc.).

L'utilisation correcte des deux dépend fortement de l'tâches que vous êtes face à lui, pour le cas spécifique. Pour le modèle de référentiel personnellement, j'ai opt pour revenir IList, c'est-à IEnumerable sur les Listes (indexeurs et autres). C'est donc mes conseils pour utiliser IQueryable seulement dans les dépôts et IEnumerable n'importe où ailleurs dans le code. Ne pas dire à propos de la testabilité des préoccupations que IQueryable se décompose et les ruines du la séparation des préoccupations principe. Si vous retournez une expression à partir de l'intérieur de référentiels les consommateurs peuvent jouer avec la couche de persistance comme ils le souhaiteraient.

Un peu plus le bordel 🙂 (à partir d'une discussion dans les commentaires))
Aucun d'entre eux sont des objets en mémoire, car ils ne sont pas les types en soi, ils sont les marqueurs d'un type - si vous voulez aller si loin. Mais elle a un sens (et c'est pourquoi même MSDN de mettre de cette façon) à penser IEnumerables que les collections en mémoire alors que IQueryables comme des arbres d'expression. Le point est que le IQueryable interface hérite de l'interface IEnumerable sorte que, si elle représente une requête, les résultats de cette requête peut être énumérés. L'énumération des causes de l'arborescence d'expression associée à un IQueryable objet à être exécuté.
Donc, en fait, on ne peut pas vraiment appeler n'importe quel IEnumerable membre sans avoir l'objet dans la mémoire. Il va y aller si vous le faites, de toute façon, si elle n'est pas vide. IQueryables sont juste des requêtes, pas les données.

OriginalL'auteur Arman McHitarian

Il y a un post de blog avec de brefs exemples de code source sur la façon de détournement de IEnumerable<T> peut avoir un impact considérable sur les performances des requêtes LINQ: Entity Framework: IQueryable vs IEnumerable.

Si nous creuser plus profondément et de le regarder dans les sources, nous pouvons voir qu'il existe bien évidemment différentes méthodes d'extension sont effectuées pour IEnumerable<T>:

//Type: System.Linq.Enumerable
//Assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
//Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Core.dll
public static class Enumerable
{
    public static IEnumerable<TSource> Where<TSource>(
        this IEnumerable<TSource> source, 
        Func<TSource, bool> predicate)
    {
        return (IEnumerable<TSource>) 
            new Enumerable.WhereEnumerableIterator<TSource>(source, predicate);
    }
}

et IQueryable<T>:

//Type: System.Linq.Queryable
//Assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
//Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Core.dll
public static class Queryable
{
    public static IQueryable<TSource> Where<TSource>(
        this IQueryable<TSource> source, 
        Expression<Func<TSource, bool>> predicate)
    {
        return source.Provider.CreateQuery<TSource>(
            Expression.Call(
                null, 
                ((MethodInfo) MethodBase.GetCurrentMethod()).MakeGenericMethod(
                    new Type[] { typeof(TSource) }), 
                    new Expression[] 
                        { source.Expression, Expression.Quote(predicate) }));
    }
}

Le premier retourne énumérable itérateur, et le second crée de la requête par le biais de la requête fournisseur, spécifié dans IQueryable source.

OriginalL'auteur Olexander Ivanitskyi

J'ai récemment rencontré un problème avec IEnumerable v. IQueryable. L'algorithme utilisé d'abord effectué une IQueryable requête afin d'obtenir un ensemble de résultats. Ces données ont ensuite été transmis à un foreach boucle, avec les éléments instanciés comme une Entité Cadre (EF) de la classe. Cet EF classe a ensuite été utilisé dans le from clause de Linq to Entité de requête, à l'origine du résultat à IEnumerable.

Je suis assez nouveau à l'EF et Linq pour les Entités, de sorte qu'il a fallu un certain temps pour comprendre ce que le goulot d'étranglement a été. À l'aide de MiniProfiling, j'ai trouvé la requête, puis converti l'ensemble de ces opérations individuelles à un seul IQueryable Linq pour les Entités de la requête. Le IEnumerable a pris 15 secondes et le IQueryable a pris de 0,5 secondes à s'exécuter. Il y avait trois tables impliquées et, après cette lecture, je crois que le IEnumerable requête a été fait en formant un trois de la table de la croix-produit et de filtrer les résultats.

Essayez d'utiliser IQueryables comme une règle-de-pouce et le profil de votre travail pour faire vos modifications mesurables.

OriginalL'auteur sscheider

La principale différence entre “IEnumerable” et “IQueryable” où la logique de filtre est exécuté. On exécute côté client (dans la mémoire) et de l'autre s'exécute sur la base de données.

Par exemple, on peut considérer un exemple où nous avons 10 000 enregistrements d'un utilisateur dans notre base de données et disons seulement 900 qui sont des utilisateurs actifs, dans ce cas, si nous utilisons la “IEnumerable” alors tout d'abord il charge tous les 10 000 enregistrements dans la mémoire, puis applique le filtre est actif sur ce qui renvoie finalement l'900 utilisateurs actifs.

Tandis que de l'autre main sur le même cas, si nous utilisons la “IQueryable” il va directement appliquer le filtre est actif sur la base de données directement à partir de là sera de retour le 900 utilisateurs actifs.

Référence Lien

OriginalL'auteur Tabish Usman

En plus des 2 premières bonnes réponses (par driis & par Jacob) :

IEnumerable
l'interface est dans le Système.Les Collections de l'espace de noms.

L'objet IEnumerable représente un ensemble de données dans la mémoire et peut se déplacer sur ces données uniquement vers l'avant. La requête représentée par l'objet IEnumerable est exécuté immédiatement et complètement, de sorte que l'application reçoit les données rapidement.

Lorsque la requête est exécutée, IEnumerable charge toutes les données, et si nous avons besoin de filtre, le filtrage se fait sur le côté client.

IQueryable interface est situé dans le Système.Linq espace de noms.

Le IQueryable objet fournit un accès à distance à la base de données et vous permet de naviguer à travers les données dans un ordre direct du début à la fin, ou dans l'ordre inverse. Dans le processus de création d'une requête, l'objet retourné est IQueryable, la requête est optimisée. En conséquence, moins la mémoire est consommée lors de son exécution, à moins de bande passante réseau, mais en même temps, il peut être traité un peu plus lentement qu'une requête qui retourne un objet IEnumerable.

Que choisir?

Si vous avez besoin de l'ensemble de données retourné, alors il est préférable d'utiliser IEnumerable, qui fournit le maximum de vitesse.

Si vous N'avez PAS besoin de l'ensemble des données renvoyées, mais seulement une partie des données filtrées, puis il est préférable d'utiliser IQueryable.

OriginalL'auteur Gleb B