Blog de Matthieu MEZIL » LINQ

LINQ Select VB != Select C# quand on fait un select sur un type anonyme

Matthieu MEZIL — Sat, 13 Oct 2007 07:48:10 +0000

Imaginons une classe Personne avec plusieurs propriétés telles que le Nom, Prenom, DateNaissance, Adresse, etc.

Pour créer un type anonyme en C#, il suffit de faire :

new { Nom = p.Nom, Prenom = p.Prenom }

Dans ce cas, les noms des propriétés étant les mêmes, on pourra même directement écrire :

new { p.Nom, p.Prenom }

De la même manière, en VB, il suffit d’écrire

New With { p.Nom, p.Prenom }

Si vous voulez faire une requête LINQ et ne renvoyer que le nom et le prénom, il faut utiliser un type anonyme.

Fort logiquement, en C#, il faut faire :

from p in persons select new {p.Nom, p.Prenom}

En VB, le type anonyme va être créé pour nous avec l’écriture suivante (plus proche du SQL) :

from p in persons select p.Nom, p.Prenom

LINQ : attention à bien l’utiliser

Matthieu MEZIL — Sat, 03 Nov 2007 20:42:55 +0000

Le défaut de LINQ c’est qu’il va devenir beaucoup plus facile de faire du code moins performant.
Prenons un exemple :

public class Client
{
private List _factures;

public string Nom { get; set; }
public string Prenom { get; set; }
public List Factures
{
get
{
if (_factures == null)
_factures = new List();
return _factures;
}
}
}

public class Facture
{
private Client _client;

public Client Client
{
get { return _client; }
set
{
if (_client != null)
_client.Factures.Remove(this);
_client = value;
_client.Factures.Add(this);
}
}
public decimal Prix { get; set; }
}

Imaginons que l’on veuille récupérer les clients ayant dépensé au moins 50 euros en les triant par ordre décroissant de dépense, puis alphabétiquement.

Le code en C# 2.0 pourrait être le suivant :

List copyClients = new List();
copyClients.AddRange(clients);

copyClients.Sort(delegate(Client x, Client y)
{
decimal xFacturesSomme = 0, yFacturesSomme = 0;
foreach (Facture facture in x.Factures)
xFacturesSomme += facture.Prix;
foreach (Facture facture in y.Factures)
yFacturesSomme += facture.Prix;
int compareFactureSomme = xFacturesSomme.CompareTo(yFacturesSomme);
if (compareFactureSomme != 0)
return -compareFactureSomme;
int compareNom = x.Nom.CompareTo(y.Nom);
if (compareNom != 0)
return compareNom;
return x.Prenom.CompareTo(y.Prenom);
});
foreach (Client c in copyClients)
{
decimal facturesSomme = 0;
foreach (Facture facture in c.Factures)
facturesSomme += facture.Prix;
if (facturesSomme > 50)
Console.WriteLine("{0} {1} a dépensé {2} euros", c.Nom, c.Prenom, facturesSomme);
}

Avec LINQ, ce code peut être grandement simplifié. Mais attention, on pourrait écrire ceci :

foreach (var statClient in from c in
(from client in clients
select new
{
client.Nom,
client.Prenom,
TotalDepense = (from f in client.Factures
select f.Prix).Sum()
})
where c.TotalDepense > 50
orderby c.TotalDepense descending, c.Nom, c.Prenom
select c)
Console.WriteLine("{0} {1} a dépensé {2} euros", statClient.Nom, statClient.Prenom, statClient.TotalDepense);

Cependant, analysons de plus près ce code :

Pour calculer la somme totale dépensée par le client, nous parcourons toutes les factures pour récupérer un IEnumerable sur le prix de celles-ci, puis nous reparcourons cet IEnumerable pour faire la somme.

L’idée serait donc de regrouper ces deux boucles en une seule. Pour cela, utilisons une lambda expression et une autre signature de la méthode Sum :

foreach (var statClient in from c in
(from client in clients
select new
{
client.Nom,
client.Prenom,
TotalDepense = client.Factures.Sum(f => f.Prix)
})
where c.TotalDepense > 50
orderby c.TotalDepense descending, c.Nom, c.Prenom
select c)
Console.WriteLine("{0} {1} a dépensé {2} euros", statClient.Nom, statClient.Prenom, statClient.TotalDepense);

L’autre problème que l’on peut identifier, c’est le fait que nous parcourons une première boucle sur les clients pour récupérer un IEnumerable de type anonyme avec le nom, le prénom et la somme dépensée et qu’ensuite, nous reparcourons cet IEnumerable pour les trier. Effectivement, pour pouvoir trier par la somme dépensée, il faut au préalable l’avoir calculée.

Là encore, une meilleure utilisation de LINQ pourrait nous permettre d’optimiser cela :

foreach (var statClient in from c in clients
let totalDepense = c.Factures.Sum(f => f.Prix)
where totalDepense > 50
orderby totalDepense descending, c.Nom, c.Prenom
select new
{
c.Nom,
c.Prenom,
TotalDepense = totalDepense
})
Console.WriteLine("{0} {1} a dépensé {2} euros", statClient.Nom, statClient.Prenom, statClient.TotalDepense);

Via ce post, je cherche à démontrer deux choses :
la requête LINQ est beaucoup plus simple et claire que le code C# 2.0.
une mauvaise connaissance de LINQ peut engendrer des pertes de performances importantes.

En revanche, avec LINQ To SQL, même si je ne vous conseille bien entendu pas d’écrire de « mauvaises » requêtes, la requête SQL générée est optimisée. Dans les trois cas précédents, la requête sera la suivante :

SELECT [t2].[Nom], [t2].[Prenom], [t2].[value] AS [TotalDepense]
FROM (
SELECT [t0].[Nom], [t0].[Prenom], (
SELECT SUM([t1].[Prix])
FROM [dbo].[Facture] AS [t1]
WHERE [t1].[Client] = [t0].[Id]
) AS [value]
FROM [dbo].[Client] AS [t0]
) AS [t2]
WHERE [t2].[value] > @p0
ORDER BY [t2].[value] DESC, [t2].[Nom], [t2].[Prenom]

Le risque lié à une mauvaise connaissance de LINQ peut cependant être fortement réduit avec une formation (http://www.winwise.fr/formation/Presentation-de-LINQ-W095.aspx par exemple).

VS 2008 sortie fin novembre

Matthieu MEZIL — Mon, 05 Nov 2007 22:33:25 +0000

C’est officiel, VS 2008 sortira fin novembre. Que du bonheur en perspective

VS 2008 Beta 2 – En attendant la RTM

Matthieu MEZIL — Sat, 03 Nov 2007 22:22:53 +0000

Si vous utilisez la Beta 2, vous avez sûrement eu le même problème que moi : la version expire au 1er novembre
Il faut retélécharger les images pour ne plus avoir de limitation.

Update LINQ To SQL : toutes les colonnes, non pas forcément

Matthieu MEZIL — Sun, 28 Oct 2007 19:05:31 +0000

J’avais blogué sur le fait que le Update de LINQ To SQL se faisait sur toutes les colonnes, y compris celles qui n’ont pas changés, ce qui peut poser des problèmes si vous avez des triggers sur le update de la table SQL.
En réalité, j’avais bloggué un peu vite. En effet, de même qu’il est possible de ne charger des colonnes qu’au moment de l’utilisation de la propriété associée (Delay Loaded = true) avec System.Data.Linq.Link, il est possible de ne pas inclure une colonne à l’update si celle-ci n’a pas été modifiée avec l’attribut UpdateCheck=UpdateCheck.WhenChanged.

Vous pouvez retrouver Delay Loaded et Update Check dans la property grid du designer LINQ To SQL.

Comment récupérer le context depuis un IQueryable

Matthieu MEZIL — Fri, 19 Oct 2007 23:32:20 +0000

Imaginons le cas suivant :
J’ai une instance vers un IQueryable d’entities (exactement un System.Data.Linq.DataQuery) mais je n’ai plus de référence vers le context utilisé pour créer la requête. En parcourant les éléments de mon IQueryable, je peux les modifier. Ensuite, il ma faut appeler la méthode SubmitChanges() sur le context pour que ces modifications soient persistantes en base.
Or, comme je l’ai dit, je n’ai plus de référence sur le contexte.
La seule solution que j’ai trouvé est la suivante : passé par la reflexion pour accéder à un champ privé d’une classe internal au Framework (System.Data.Linq.DataQuery) et récupérer ainsi le DataContext :

var qDb = (DataClasses1DataContext)(q.GetType().GetField("context", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(q));
qDb.SubmitChanges();

Cela marche effectivement avec les Table mais pour les EntitySet, cela est plus compliqué. On peut supposait que T est un Table et par conséquent, récupérer le context par reflexion mais la seule contrainte sur T est que ce soit une classe :

public sealed class EntitySet : IList, ICollection, IList, ICollection, IEnumerable, IEnumerable, IListSource, IEntitySet where TEntity: class

Donc en gros, ne perdez pas de référence sur un DataContext si vous gardez une référence vers une query.

OnValidate

Matthieu MEZIL — Wed, 24 Oct 2007 22:01:02 +0000

Je viens d’avoir une énorme surprise en regardant de plus près le code généré par le designer de LINQ To SQL.
Dans chaque classe d’entité, il y a une partial method OnValidate. Cependant cette méthode n’est jamais appelée ! En fait si, elle est appelée par la classe ChangeProcessor, dans la méthode ValidateAll… par reflexion !!!

Bien comprendre les bases de LINQ To Objects

Matthieu MEZIL — Mon, 22 Oct 2007 07:39:50 +0000

Frédéric Mélantois vient de publier son article « Bien comprendre les bases de LINQ To Objects »

Update de LINQ To SQL : Toutes les colonnes :(

Matthieu MEZIL — Thu, 18 Oct 2007 23:01:31 +0000

J’avais précédemment blogué sur mon regret que le Update du SQLDataAdapter généré par le designer de DataSet faisait un Update sur toutes les colonnes, y compris celles qui n’avaient pas été modifié.
C’est pareil avec LINQ To SQL

.Net 3.5, quelles sont les nouveautés

Matthieu MEZIL — Thu, 18 Oct 2007 15:09:34 +0000

Je viens de tomber vraiment par hasard sur un excellent article de Grégory Renard qui reprend l’ensemble des nouveautés de .NET 3.5.