N’utilisez Single que quand c’est nécessaire sinon utilisez First !
J’ai vu plusieurs développeurs utiliser la méthode Single quand ils voulaient récupérer un élément alors qu’ils savaient que le Single ne retournerait qu’un seul élément. C’est mal !!!
Dans ce cas, il faut utiliser la méthode First.
Le but de la méthode Single est de retourner un seul élément (comme la méthode First) mais aussi de s’assurer qu’il n’y a bien qu’un seul résultat.
Concrètement, qu’est-ce que cela signifie. Regardons de plus près le code suivant :
int tick = Environment.TickCount;
int value = Enumerable.Range(0, int.MaxValue).First(i => i == 10);
Console.WriteLine(Environment.TickCount - tick); La console affiche 62. La méthode First a parcouru 11 éléments dans la collection.
Maintenant faisons la même chose avec Single :
int tick = Environment.TickCount;
int value = Enumerable.Range(0, int.MaxValue).Single(i => i == 10);
Console.WriteLine(Environment.TickCount - tick); La console affiche 28720 ! La méthode a parcouru les 2147483648 éléments pour s’assurer qu’il n’y avait pas de doublon !
cqfd
C’est la même chose avec LINQ To Entities. Avec un First, c’est une requête SQL avec un TOP 1 qui sera exécutée ; avec un Single, c’est une requête SQL avec un TOP 2 qui sera exécutée ce qui aura bien sûr une incidence sur les perfs. Bien entendu, si vous vous limittez à une condition sur une colonne indexée, l’impact sera quasi nul.
Alors oui le Single (ou SingleOrDefault) c’est utile mais si et seulement si on veut s’assurer qu’il n’y a bien qu’un seul élément (et lever une exception dans ce cas). Si ce n’est pas le cas, il faut la bannir du code et lui préférer la méthode First (ou FirstOrDefault).
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
