Un framework a beau être super puissant, il ne peut pas empêcher l'a mauvaise utilisation. Il peut tenter par de nombreux moyens de la réduire mais il ne peut l’empêcher.
Du moins pas sans se brider par la suite.
J’en veux pour preuve l’utilisation d’Entity Framework 4.0. Ce framework permet de manière extrêmement élégante de requêter une source de données. Et, bien utilisé, il permet aussi d’être très performant.
Voici un exemple issu d’UrzaGatherer: Mon modèle possède une collection de Card qui, entre autres, contient une propriété Check qui permet de définir si l’utilisateur détient complètement la carte en question. Dans le cadre de la treeview qui affiche les collections de cartes, je voulais modifier le texte de chaque collection en y ajoutant le nombre de cartes manquantes le cas échéant.
Pour se faire et comme tout est issu du binding dans UrzaGatherer, j’ai développé un ValueConverter utilisé ainsi:
<TextBlock Text="{Binding Converter={StaticResource CountConverter}, Mode=OneWay
, IsAsync=True}" />
Le code du converter était le suivant:
public class CountConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter,
CultureInfo culture)
{
Expansion expansion = (Expansion) value;
var query = from card in MainWindow.Entities.Cards
where card.ExpansionID == expansion.ID
select card;
int check = 0;
List<Card> cards = query.ToList();
int count = cards.Count;
foreach (Card card in cards)
{
if (card.Check)
check++;
}
int missing = count - check;
if (missing == 0)
return string.Format("- {0} cards", count);
return string.Format("({0}/{1} - Missing : {2})", check, count, missing);
}
public object ConvertBack(object value, Type targetType, object parameter,
CultureInfo culture)
{
return value;
}
}
Dans ce converter, on voit donc une requête LINQ sur les cartes en question, puis une transformation en liste pour faire notre comptage.
Et c’est là qu’apparait la mauvaise utilisation. En effet, la conversion en liste va effectivement faire la requête sur la base de données et créer les entités en mémoire. Ces entités qui peuvent être lourdes (c’est le cas ici ou chaque carte porte plusieurs images).
Tout ça pour juste obtenir un comptage.
Il faut garder à l’esprit que EF4 est efficace tant qu’on reste dans le monde des expressions LINQ, c’est à dire tant qu’on reste au final dans le monde SQL.
Ici par exemple, la solution pour être bien plus efficace est simple : Il ne faut pas utiliser de listes locales mais tout traiter en LINQ:
public object Convert(object value, Type targetType, object parameter,
CultureInfo culture)
{
Expansion expansion = (Expansion) value;
var query = from card in MainWindow.Entities.Cards
where card.ExpansionID == expansion.ID
select card;
int check = query.Count(c => c.Check);
int count = query.Count();
int missing = count - check;
if (missing == 0)
return string.Format("- {0} cards", count);
return string.Format("({0}/{1} - Missing : {2})", check, count, missing);
}
La différence est subtile mais ici tout se passera sur SQL Server. Aucune entité ne sera créée ni ramenée côté client. Les méthodes Count() issues de LINQ vont générer des requêtes efficaces côté serveur contrairement à la méthode ToList() qui va faire un bon gros SELECT des familles pour tout reconstruire en mémoire.
Donc en conclusion et en ce qui concerne Entity Framework 4.0 : Retardez toujours au plus tard la récupération des entités!!
.Net, WPF
Optimisation, EF 4