Entity Framework .Où la méthode de chaînage

Quelle est la différence entre ces deux manières d'interroger le contexte?

Firm firm = base.context.Firms
            .Where(f => f.SomeId == someId)
            .Where(f => f.AnotherId == anotherId)
            .FirstOrDefault();

Firm firm = base.context.Firms
            .Where(f => f.SomeId == someId && f.AnotherId == anotherId)
            .FirstOrDefault();

Il semble que le chaînage est parfaitement bien à accomplir ET de l'état. Je ne crois pas que vous pouvez de la chaîne OU de déclarations. Est-il une raison de préférer l'une sur l'autre, ou les scénarios lorsque l'on est mieux/plus efficace?

InformationsquelleAutor e36M3 | 2010-11-04
  1. 41

    Elles doivent produire le même résultat final (si je ne me trompe pas) mais je trouve que le deuxième est plus lisible et mieux apparaître l'intention d'origine.

    Mise à jour

    Je viens de vérifié la déclaration ci-dessus à l'aide de LINQPad. Les deux requêtes, en fait, produit de la même SQL.

    Par exemple:

    context.SomeTable.Where(c => c.ParentId == null)
                 .Where(c => c.Name.Contains("F"))
                 .Select(c => c.Name);

    Produit:

    SELECT [t0].[Name] 
FROM [SomeTable] AS [t0]
WHERE ([t0].[Name] LIKE @p0) AND ([t0].[ParentId] IS NULL)

    Qui est le même SQL qui est produit par:

    context.SomeTable.Where(c => c.ParentId == null && c.Name.Contains("F"))
                 .Select(c => c.Name);

    Vous pouvez aussi compact choses un peu plus (que je trouve préférable pour les mêmes raisons que ci-dessus):

    var firm = base.context.Firms.FirstOrDefault(f => f.SomeId == someId 
                                                  && f.AnotherId == anotherId);
    • +1 pour des raisons de lisibilité
    • +1 pour LinqPad.
    • La première est la plus lisible pour moi. Vous pouvez immédiatement voir il y a deux conditions qui doivent correspondre et ils s'alignent parfaitement. Sûr que la seconde dispose également de deux conditions, mais il prend la seconde à analyser qu'il y a un && dans la ligne.
    • +1 pour LINQPad. LINQPad: linqpad.net. C'est un merveilleux petit outil pour LINQ.
    • J'ai une question concernant votre dernière syntaxe (FirstOrDefault(Prédicat...)), étant donné que ObjectQuery implémente à la fois IEnumerable et IQueryable, qu'est-ce que le compilateur de résolution de surcharge algorithme pour choisir IQueryable.FirstOrDefault() sur IEnumerable.FirstOrDefault (), de sorte que vous voyez le prédicat s'affiche dans le SQL généré le Profileur ou LINQPad? Pour plus d'informations, veuillez jeter un oeil à ma réponse à cette question: stackoverflow.com/questions/4047266/... Merci.
    • (La réalisation de ce Q&A est désormais de plus que certains élèves de deuxième année...) Bizarrement, en EF de Base, j'ai une requête qui s'exécute uniquement la dernière comparaison, si je && dans un seul Where(), mais si je mets chaque clause dans son propre .Where(l =>...), je suis d'or. /preStandupFaceRubAndShrug ;^D

    InformationsquelleAutor Justin Niessner
  2. 2

    Ma conjecture est que tant que vous travaillez dans le IQueryable (comme votre contexte, les collections sont sans doute), à l'aide de l'enchaînement des extensions de vs le plein de prédicat de la clause réalise la même chose. C'est parce que IQueryable permet l'exécution différée donc essentiellement les mêmes SQL est généré en coulisses.

    InformationsquelleAutor dotariel
  3. 0

    Vous pouvez déboguer le code et voir le SQL, qui est généré à la suite de chaque. J'imagine qu'il tourne dans la même requête.

    InformationsquelleAutor skaz