Préserver l'ordre avec LINQ

J'utilise les instructions LINQ to Objects sur un tableau ordonné. Quelles opérations ne dois-je pas faire pour être sûr que l'ordre du tableau n'est pas modifié?

J'ai examiné les méthodes de System.Linq.Enumerable , en rejetant toutes celles qui renvoyaient des résultats non IEnumerable. J'ai vérifié les remarques de chacun pour déterminer en quoi l'ordre du résultat différerait de l'ordre de la source.

Préserve l'ordre absolument. Vous pouvez mapper un élément source par index à un élément de résultat

• AsEnumerable
• Jeter
• Concat
• Sélectionner
• ToArray
• Lister

Préserve l'ordre. Les éléments sont filtrés ou ajoutés, mais pas réorganisés.

• Distinct
• Sauf
• Couper
• OfType
• Prepend (nouveau dans .net 4.7.1)
• Sauter
• SkipWhile
• Prendre
• TakeWhile
• Où
• Zip (nouveau dans .net 4)

Détruit l'ordre - nous ne savons pas dans quel ordre s'attendre.

• ToDictionary
• Pour rechercher

Redéfinit explicitement l'ordre - utilisez-les pour modifier l'ordre du résultat

• Commandé par
• OrderByDescending
• Inverser
• Puis par
• ThenByDescending

Redéfinit l'ordre selon certaines règles.

• GroupBy - Les objets IGrouping sont générés dans un ordre basé sur l'ordre des éléments dans la source qui ont produit la première clé de chaque IGrouping. Les éléments d'un regroupement sont générés dans l'ordre dans lequel ils apparaissent dans la source.
• GroupJoin - GroupJoin préserve l'ordre des éléments de l'extérieur, et pour chaque élément de l'extérieur, l'ordre des éléments correspondants de l'intérieur.
• Join - préserve l'ordre des éléments de l'extérieur et, pour chacun de ces éléments, l'ordre des éléments correspondants de l'intérieur.
• SelectMany - pour chaque élément de la source, le sélecteur est appelé et une séquence de valeurs est renvoyée.
• Union - Lorsque l'objet renvoyé par cette méthode est énuméré, Union énumère les premier et deuxième dans cet ordre et renvoie chaque élément qui n'a pas déjà été généré.

Edit: J'ai déplacé Distinct à l'ordre de conservation basé sur cette implémentation .

    private static IEnumerable<TSource> DistinctIterator<TSource>
      (IEnumerable<TSource> source, IEqualityComparer<TSource> comparer)
    {
        Set<TSource> set = new Set<TSource>(comparer);
        foreach (TSource element in source)
            if (set.Add(element)) yield return element;
    }

Parlez-vous réellement de SQL ou de tableaux? En d'autres termes, utilisez-vous LINQ to SQL ou LINQ to Objects?

Les opérateurs LINQ to Objects ne changent pas réellement leur source de données d'origine - ils construisent des séquences qui sont efficacement soutenues par la source de données. Les seules opérations qui modifient l'ordre sont OrderBy / OrderByDescending / ThenBy / ThenByDescending - et même alors, celles-ci sont stables pour des éléments également ordonnés. Bien sûr, de nombreuses opérations filtreront certains éléments, mais les éléments renvoyés seront dans le même ordre.

Si vous convertissez vers une structure de données différente, par exemple avec ToLookup ou ToDictionary, je ne crois pas que l'ordre soit préservé à ce stade - mais c'est quelque peu différent de toute façon. (L'ordre des valeurs mappées à la même clé est cependant conservé pour les recherches, je crois.)

Si vous travaillez sur un tableau, il semble que vous utilisez LINQ-to-Objects, pas SQL; pouvez-vous confirmer? La plupart des opérations LINQ ne réordonnent rien (la sortie sera dans le même ordre que l'entrée) - donc n'appliquez pas un autre tri (OrderBy [Descending] / ThenBy [Descending]).

[modifier: comme Jon l'a dit plus clairement; LINQ crée généralement une nouvelle séquence, laissant les données originales seules]

Notez que pousser les données dans un Dictionary<,>(ToDictionary) brouillera les données, car le dictionnaire ne respecte aucun ordre de tri particulier.

Mais les choses les plus courantes (sélectionner, où, sauter, prendre) devraient convenir.

J'ai trouvé une excellente réponse dans une question similaire qui fait référence à la documentation officielle. Pour le citer:

Pour les Enumerableméthodes (LINQ to Objects, qui applique List<T>), vous pouvez compter sur l'ordre des éléments retournés par Select, Whereou GroupBy. Ce n'est pas le cas pour les choses qui sont intrinsèquement non ordonnées comme ToDictionaryou Distinct.

De la documentation Enumerable.GroupBy :

Les IGrouping<TKey, TElement>objets sont livrés dans un ordre basé sur l'ordre des éléments en source qui ont produit la première clé de chacun IGrouping<TKey, TElement>. Les éléments d'un regroupement sont générés dans l'ordre dans lequel ils apparaissent source.

Ce n'est pas nécessairement vrai pour les IQueryableméthodes d'extension (autres fournisseurs LINQ).

Source: Les méthodes énumérables de LINQ maintiennent-elles l'ordre relatif des éléments?

Tout «groupé par» ou «commandé par» modifiera éventuellement la commande.

La question ici se réfère spécifiquement à LINQ-to-Objects.

Si vous utilisez LINQ-to-SQL à la place, il n'y a pas d'ordre, sauf si vous en imposez un avec quelque chose comme:

mysqlresult.OrderBy(e=>e.SomeColumn)

Si vous ne le faites pas avec LINQ-to-SQL, l'ordre des résultats peut varier entre les requêtes suivantes, même des mêmes données, ce qui pourrait provoquer un bogue intermittent.