Etude exploratoire de Linq - CoDE - de l'Université libre de Bruxelles

Faculté des Sciences appliquées
Année académique 2009 - 2010
Etude exploratoire de Linq
Directeur de mémoire : Mémoire présenté par
Dr. Ir. Hugues Bersini Charles Schoonenbergh
En vue de l’obtention du
diplôme de Master en
ingénieur civil informaticien,
spécialité ingénierie
informatique

Abstract
Linq est une technologie apparue avec C# 3 et VB 2008 et a été présenté comme un gigantesque bon
en avant dans le domaine de la gestion des données. La présente étude se propose d’explorer Linq
depuis ses fondements jusqu’à l’analyse de plusieurs mises en situation. L’étude débutera par
l’analyse des enrichissements syntaxiques apportés avec C# 3 pour ensuite définir le formalisme de
requêtes utilisé par Linq. Linq se décline en une série d’implémentations, celles-ci seront examinées
en détails en commençant par Linq to Object. Ensuite viendra le tour de Linq to Sql. Cette
implémentation étant source de beaucoup de controverse, une attention toute particulière y sera
apportée. Plusieurs tests de mise en œuvre seront appliqués, notamment en ce qui concerne les
performances relatives à un code équivalent rédigé avec la couche ADO.NET classique. D’autres
implémentations relationnelles seront étudiées comme Linq to DataSet, Linq to Entities exploitant la
toute nouvelle technologie Entity Framework et une brève analyse de l’implémentation Db Linq sera
faite. L’implémentation Linq to Xml sera ensuite étudiée, présentant les nouveautés liées à la gestion
du contenu Xml. Un bilan des nouveautés proposées par Linq sera ensuite établi et l’étude se
terminera par l’analyse des alternatives à Linq, que ce soit pour la plateforme .NET ou pour d’autres
langages orientés objet, ainsi que Java, PHP ou Python.

Table des matières
Conventions d’écriture 1
Introduction 2
1. Vue d’ensemble 3
2. Mécanismes sous-jacents 4
2.1 Quelques rappels 4
2.1.1 Généricité 4
2.1.2 Délégués 4
2.1.3 Méthodes anonymes 5
2.2 Enrichissements syntaxiques 6
2.2.1 Inférence sur le typage 6
2.2.2 Expressions lambda 7
2.2.3 Expressions arborescentes 7
2.2.4 Extensions de méthode 11
2.2.5 Formalisme d’une requête 11
3. Implémentation Objets 13
3.1 Champ d’application 13
3.2 Quelques opérateurs à la loupe 14
3.2.1 Projection groupée 14
3.2.2 Inversion et indexes 14
3.2.3 Groupement 14
3.2.4 Quantificateurs 15
3.2.5 Conversion en énumérable 15
3.3 Exemple illustratif 16
4. Implémentations relationnelles 18
4.1 Entités en mémoire 18
4.2 Linq to SQL 18
4.2.1 Mapping 19
4.2.1.1 Syntaxe au niveau du code 19
4.2.1.2 Principe et fonctionnement 19
4.2.1.3 Gestion par le DataContext 21

4.2.2 Opérations fondamentales 22
4.2.3 Cas pratiques 23
4.2.4 Erreurs et difficultés 26
4.2.5 Performances 29
4.2.5.1 Test d’insertion 29
4.2.5.2 Test en situation concurrentielle 31
4.2.6 Conclusion 32
4.3 Linq to DataSet 33
4.4 Linq to Entities 35
4.4.1 Concept fondateur 35
4.4.2 Fonctionnement 36
4.4.3 Mapping 37
4.4.4 Rôlede Linq 38
4.5 Db Linq 38
5. Implémentation XML 39
6. En pratique 41
6.1 Ressenti général 41
6.2 Points forts, points faibles 41
6.3 Quelles alternatives ? 43
6.3.1 Java 43
6.3.1.1 JDO 43
6.3.1.2 Hibernate 44
6.3.2 .NET 45
6.3.2.1 NHibernate 45
6.3.2.2 Entity Framework 45
6.3.3 Autres langages 46
6.3.3.1 Persistance personnalisée 46
6.3.3.2 Bases de données objets 47
6.4 Evolutions de Linq 48
6.4.1 Version 4 48
6.4.2 Ce qui reste à améliorer 48
6.4.3 Linq et Mono 49
Conclusion 50

Bibliographie 51
Annexe 1 : Code de l’exemple Linq to object 52
Annexe 2 : Code de test de performance Linq to Sql 55
Annexe 3 : Utilisation d’une base de données MySql avec Linq to DataSet 65

Conventions d’écriture
Afin de rendre plus aisée la lecture de ce document, des conventions d’écriture ont été adoptées.
Les termes faisant référence à une classe, un assemblage ou une méthode seront écrits en italique et
dans le respect de la casse originale, comme ceci : Methode définie pour telle Classe.
Les termes faisant références à des procédures ou à des techniques bien connues seront écrit avec
une majuscule pour mieux ressortir, comme ceci :
La clause Select du langage Sql.
Les extraits de code seront présentés dans une police spéciale pour bien ressortir du texte principal.
En outre, un alinéa supplémentaire sera observé, comme ceci :
Ceci est un extrait de code;
Les références à des sites internet se feront comme des références classiques lorsque le site contient
de l’information dont le présent écrit est inspiré. Lorsque du contenu est cité explicitement, une note
de bas de page présentera l’adresse web exacte.

Introduction
Depuis l’apparition des langages orientés objet, le problème de la persistance des données a toujours
été crucial. Un programme incapable de retenir ce qui s’est passé lors de sa précédente exécution ne
présente qu’un intérêt limité. Malheureusement aucun langage orienté objet n’a de prise directe sur
cette capacité de persistance. Des systèmes de stockage se sont développés, certains très antérieurs
aux langages orientés objet eux-mêmes. C’est le cas des bases de données relationnelles qui stockent
l’information sous forme de tables ayant des relations entre elles. Ce mode de stockage c’est petit à
petit imposé comme acteur principal lorsqu’il s’agit d’enregistrer des informations depuis un
programme. L’ennui est que les langages de programmation actuels ne s’interfacent pas
parfaitement avec ce type de persistance. Depuis longtemps déjà, des solutions sont mises en œuvre
pour palier à ce problème.
Réaliser un interfaçage n’est pas tout, il reste le problème de la dépendance au niveau du code. Si
changer le système d’enregistrement des données implique de réécrire la moitié de l’application qui
les utilise, la situation est gênante. L’abstraction envers le stockage a ses limites, lui aussi. Les bases
de données orientées objet et plus tard leurs homologues basées sur Xml sont venues s’ajouter dans
le paysage moderne de la persistance. Ces gestionnaires de données n’utilisent cependant pas le
même langage et passer de l’un à l’autre sans rien changer est tout simplement irréalisable. Nous
avons donc actuellement affaire à des applications mêlant plusieurs langages de programmation,
généralement de l’orienté objet couplé à un langage de requêtes propre à la source de données.
C’est là que la tâche du développeur se complique. Il faut non seulement maîtriser plusieurs langages
mais en plus pouvoir interfacer les deux de la façon la plus abstraite possible car un changement de
politique de stockage est toujours possible.
Linq a été introduit avec C# 3 et VB 2008. Derrière cet acronyme, Language INtegrated Query, se
cache presque tout un paradigme. Une nouvelle manière d’appréhender les données, spécialement
celles qui sont persistantes. La présente étude se propose d’explorer les différentes possibilités qui
caractérisent Linq tout en gardant un œil critique sur ce que Microsoft annonce comme étant LA
révolution dans le monde de la programmation. Nous tenterons dans un premier temps de mettre en
lumière les solutions techniques qui ont été mises en œuvre avec Linq. La question du champ
d’application sera ensuite abordée, passant en revue les différentes implémentations de Linq : ce
qu’il peut faire ou ne pas faire et quels types de données il peut cibler. Nous nous intéresserons tout
particulièrement au cas des données relationnelles qui restent, comme déjà précisé, un acteur
incontournable dans le domaine de la gestion des données non volatiles. Après ces différentes
études de cas, nous tenterons de faire le point sur les forces et faiblesses de Linq avant d’envisager
les alternatives à son utilisation. Viendra enfin un examen de son devenir et de ses éventuelles
évolutions avant de conclure notre étude.

Chapitre 1 : Vue d’ensemble
Dans cette section nous allons donner un avant-goût de Linq et préciser la méthode générale qui sera
suivie durant cette étude. Tout au long de ce rapport nous utiliserons le terme de Linq pour désigner
l’ensemble des fonctionnalités accessibles grâce à ses implémentations. Linq n’est pas réellement un
tout unifié mais davantage un regroupement de plusieurs API partageant une syntaxe commune. Il
est bon de garder cela en tête pour éviter toute confusion. Ce chapitre est inspiré de [1].
Comme son acronyme l’indique, Linq offre la possibilité de faire des requêtes intégrées au langage,
mais que devons-nous comprendre par là ? En réalité, le terme requête sera expliqué dans le
prochain chapitre et lorsque nous parlons de langage il s’agira de C# et VB 2008. Ces deux langages
de programmation font partie de la plateforme .NET (prononcé dotNet, à l’Anglaise), parfois aussi
appelé framework .NET. Comme abordé dans l’introduction, un problème majeur actuellement est
de devoir mélanger des langages appartenant à des paradigmes différents : en général un pour la
programmation orientée objet et l’autre pour la gestion des données stockées. L’ensemble des
difficultés engendrées par la mixité des langages est souvent appelé « impedance mismatch » dans la
littérature internationale. Ce problème d’impédance entre langages résulte souvent en une baisse de
productivité pour le développeur et une panoplie d’erreurs difficiles à débusquer car n’apparaissant
potentiellement que très tard, à l’exécution. Linq est présenté comme le remède à tous ces soucis,
offrant un seul langage où tout est vérifié à la compilation. Reste à voir quel fossé existe entre ce
genre d’annonces publicitaires et la réalité de la conception d’applications.
Cette étude a pour but d’explorer Linq et ses fonctionnalités, c'est-à-dire d’examiner de quelle façon
Linq se propose de faire la jonction entre le monde des objets et celui de leur persistance. Nous ne
prétendons pas porter de jugement sur le choix de telle ou telle manière de réaliser le stockage des
données. Il n’est pas non plus de notre ressort d’établir que tel langage de programmation est mieux
qu’un tel autre. Nous tâcherons également de rester aussi objectifs que possible dans nos
considérations, il ne s’agit pas de vanter Microsoft ou même Linq mais d’étudier ce dernier. Nous
essayerons de partir de sources documentées aussi officielles que possible pour ensuite mettre en
œuvre des cas concrets. Diverses autres sources seront cependant mentionnées mais leur caractère
non officiel sera précisé.

Chapitre 2 : Mécanismes sous-jacents
2.1 Quelques rappels
Avant de se lancer dans l’analyse des nouveautés syntaxiques, rappelons certains aspects
intéressants déjà présents dans le deuxième framework de .NET. Ces fonctionnalités sont à la base
de Linq et constituaient déjà des avancées majeures dans le domaine de l’abstraction en général. Il
s’agit des classes génériques, des méthodes anonymes ainsi que des délégués. Nous allons les passer
rapidement en revue en montrant leur intérêt du point de vue de Linq ainsi que leur rôle. Les
améliorations venues se greffer par-dessus ces mécanismes seront détaillées dans la prochaine
section. L’ensemble de cette section est principalement inspiré de *2+ pour le contenu et de *1+ pour
sa structure.
2.1.1 Généricité
La généricité, en tant que telle, a été introduite dans le langage C++ par le biais des classes
templates. Le principe, rappelons-le brièvement, est de pouvoir considérer l’exécution d’un code
sans avoir à spécifier quel type d’objets il manipulera. C#, dans sa version 2, permettait l’usage et la
définition de classes, de structures, d’interfaces et de fonctions génériques. En plus d’apporter une
plus grande sûreté dans la programmation 1 , la généricité rend également un code plus réutilisable
lorsqu’elle est utilisée. De ce fait, l’usage des génériques offre un niveau d’abstraction facile
d’emploi. Une liste peut être définie de manière générique, car les principes d’insertion, de
recherche et de suppression ne sont aucunement liés au type de contenu. A l’utilisation, la liste sera
précisée comme étant une liste d’entiers, de strings ou de n’importe quel type d’objets dont il sera
question à ce moment-là. La définition de la liste représente bien une abstraction par rapport à son
contenu et néanmoins, le compilateur remarquera les opérations illicites au niveau typage
(impossible d’ajouter un string à une liste d’entiers par exemple). La généricité est importante pour
envisager Linq, les manipulations de données (telles qu’une insertion, une suppression ou une
recherche, tout comme pour la liste) n’étant pas liées directement au contenu. Comme nous le
verrons plus loin, Linq utilise une interface générique pour manipuler des données.
2.1.2 Délégués
Les délégués sont des objets (de classe Delegate ou d’une de ses sous-classes) qui peuvent appeler
une ou plusieurs fonctions, à la manière des pointeurs de fonctions en C++. Le principe n’est pas
nouveau, son origine remonte au C++ comme nous venons de le préciser. Ce qui est nouveau, en
revanche, ce sont les facilités de syntaxes ainsi que la possibilité d’ajouter un nombre variable de
fonctions à un délégué. Un exemple illustratif inspiré de [2] mettra en lumière ces aspects à la page
suivante.
1 La généricité dans les collections permet d’encore accroître le typage et donc la vérification à la compilation.

class Exemple
{
static void f1() { Console.WriteLine("fct1"); }
static void f2() { Console.WriteLine("fct2"); }
}
delegate void T(); //declaration du delegue
static void Main(string[] args)
{
T del = new T(f1);
del += new T(f2);
}
del(); //execute les deux fonctions pointees
En lisant l’exemple ci-dessus, la première chose qui va nous intéresser est la déclaration du délégué.
Ceci correspond bien à une déclaration de type (ici un type nommé T) dont nous avons le choix de
son nom (T) et le mot clé delegate précise qu’il s’agit d’un type délégué. Il est possible d’ajouter au
délégué une ou plusieurs références à des fonctions à la condition que celles-ci respectent la
signature du délégué (ici aucun paramètre et void comme retour). C’est ce dont il s’agit dans les deux
premières lignes de la méthode Main. Lorsqu’un délégué fait référence à plusieurs fonctions, il les
exécute toutes dans l’ordre avec lequel elles ont été assignées au délégué. Ainsi, le code de
l’exemple plus haut produirait en sortie le résultat suivant :
Figure 1 : appels de délégués
Le principe des délégués est à la base des expressions lambda fortement utilisées par Linq. Comme
nous le verrons ces expressions sont spécialement utilisées dans la résolution des clauses de
requêtes (select, where …).
2.1.3 Méthodes anonymes
Les méthodes anonymes ont été introduites avec la deuxième version de .NET. Il s’agit de suites
d’instructions jouant le rôle d’une méthode, sans pour autant définir explicitement de fonction. Cela
s’utilise en conjonction avec les délégués, de la manière suivante :
del += delegate { string text = "Il est " + DateTime.Now.ToString();
Console.WriteLine(text); };
En effet aucun nom de méthode n’a été spécifié. La seule contrainte d’utilisation est qu’il est
impossible de faire marche arrière, puisque retirer la référence à cette méthode dans le délégué
implique de pouvoir nommer cette référence. En poussant le raisonnement plus loin, pourquoi ne
pas utiliser une méthode anonyme en paramètre d’une autre méthode ? La lisibilité et la
compréhensibilité du code s’en trouvent améliorées. Linq utilise les méthodes anonymes dans ce
but, améliorer la lisibilité des requêtes. Vouloir obtenir « tous les étudiants tels que leur moyenne est
supérieure ou égale à 10 et les grouper par section » s’écrirait en pseudo code :
etudiants.Where(moyenne >= 10).OrderBy(section).Select(etudiant);

Etudiants désignant une collection de données, l’appel à la méthode Where devrait prendre en
paramètre une ou plusieurs conditions à tester. Comment effectuer ces tests sans savoir au préalable
leur nombre et leur nature ? Le recours à une méthode anonyme va permettre de manipuler une ou
plusieurs conditions complexes 2 et d’extraire ainsi les objets répondant à la condition pour passer
cette nouvelle collection en paramètre de l’appel suivant et ainsi de suite. Linq fait un usage extensif
des méthodes anonymes en conjonction avec une syntaxe simplifiée (ce point sera développé lors de
la présentation des expressions lambda) pour exprimer les clauses d’une requête, comme le dernier
exemple l’a suggéré.
2.2 Enrichissements syntaxiques
Comme nous venons de le voir, certains aspects du langage C# dans sa version 2 introduisent des
fonctionnalités qui nous seront utiles pour mieux cerner les fondements de requêtes sur des
données abstraites. Nous allons maintenant aborder de nouveaux éléments syntaxiques, pour la
plupart basés sur les mécanismes que nous venons de passer en revue. Ces nouvelles fonctionnalités
vont un cran plus loin et mettent en place les bases d’un langage de requêtes. Nous allons y voir
comment le compilateur peut désormais inférer le typage d’un objet lorsque celui-ci n’est pas
spécifié, comment mettre en place les méthodes d’interrogations proprement dites et enfin nous
allons découvrir une nouvelle façon d’écrire les méthodes anonymes au moyen des expressions
lambda. Avec tous ces pré requis en place, nous allons pouvoir examiner la syntaxe globale d’une
requête au sens de Linq en y montrant le rôle de chacun des mécanismes vus jusque là. Cette section
repose essentiellement sur des informations tirées de [4] et arrangées selon une structure inspirée
de [1].
2.2.1 Inférence sur le typage
L’inférence sur le typage permet au compilateur de déduire le type de variables sans que le
développeur ait besoin de le lui signaler explicitement. Comme cette étape se passe à la compilation,
les risques d’erreur restent limités tout en autorisant une syntaxe plus libre. Le mot-clé var peut être
utilisé en lieu et place du type d’une variable et indique au compilateur que son type devra être
inféré à la compilation. A noter toutefois que l’inférence sur le typage est une opération locale et ne
peut donc être appliquée au champ d’une classe ni dans le cas d’un paramètre.
Il est important de parler, à ce stade, d’une autre nouveauté introduite par la troisième version du
framework .NET, le typage anonyme. Le typage anonyme permet de créer une variable sans en
spécifier le type ni l’appel explicite au constructeur (cette dernière particularité constitue elle aussi
une nouveauté et est disponible pour tous les types). Ainsi il est parfaitement licite d’écrire le code
suivant pour une classe Personne ayant comme attributs publics les champs Nom (de type string) et
Age (de type int) :
Personne p = new Personne { Nom = "Tartempion", Age = 40 };
var monTypeAnonyme = new { p.Nom, p.Age };
Linq étant présenté comme une couche d’abstraction dans l’accès aux données, l’intérêt d’intégrer
une telle syntaxe est évident. Un changement dans le type du champ Age (passage de integer en
short par exemple) laissera intacte la présentation des résultats de requêtes ou les modifications de
valeurs impliquant ce champ.
2 Complexe est utilisé ici pour signifier qu’on dépasse le cadre d’un simple opérateur conditionnel tel que ==.

2.2.2 Expressions lambda
Cette sous-section rassemble également des informations provenant de [1] et de [6]. Le type
delegate introduit avec la version 2 du framework .NET représente un moyen de faire pointer du
code vers une fonction définie ailleurs. L’expression lambda simplifie cette pratique et permet plus
de souplesse à l’utilisation. Ceci s’avère particulièrement utile pour l’écriture de méthodes
anonymes, comme le montre l’exemple suivant (trouvé sur [6]) :
//methode anonyme recuperant les entiers positifs, ecrite avec la
//syntaxe 2.0
List list = new List(new int[] { -1, 2, -5, 45, 5 });
List positiveNumbers = list.FindAll(delegate(int i) { return i >
0; });
//meme code ecrit avec une expression lambda
List list = new List(new int[] { -1, 2, -5, 45, 5 });
var positiveNumbers = list.FindAll((int i) => i > 0);
La syntaxe d’une expression lambda est toute simple. Elle se compose d’une liste de paramètres (un
seul, dans l’exemple ci-dessus, l’entier i), du symbole « => » intuitivement traduit par « tel que » et
d’une expression qui constitue en fait la valeur retournée par l’expression lambda. Cette formulation
est bien plus lisible et se prononce « tous les entiers i tels que la valeur de i est strictement
supérieure à 0 ». Un autre avantage est que la valeur retournée par l’expression lambda est typée
implicitement, comme l’indique le mot-clé var dans l’exemple précédent.
En plus d’une simplicité d’écriture pour les méthodes anonymes, les expressions lambda permettent
de traiter des expressions proches des clauses Sql. Ainsi une clause Where dans une requête Sql peut
se voir comme une condition de filtrage du résultat. Pour exprimer ceci en termes d’expressions
lambda, nous appelons notre condition de filtrage définie par une expression lambda sur le résultat,
de cette manière résultat.Filtrage(conditions). Le résultat de ce filtrage peut être lui-même soumis à
d’autres opérations de ce type, présentant l’avantage de pouvoir lire les opérations séquentiellement
de gauche à droite : résultat.Filtre1( condition1.1, condition1.2).Filtre2( condition2.1, … condition2.n)
et ainsi de suite. C’est ainsi que Linq en fait usage, pour passer à chaque opérateur de clause le
résultat créé par l’appel des clauses précédentes : EnsembleFrom.Where(clause where).Select(clause
select).OrderBy(critère de tri). Nous ne parlons ici que des clauses au sens relationnel du terme, le Sql
étant devenu en quelque sorte le standard pour interroger des données, nous nous contentons
d’utiliser ici l’analogie. Nous verrons plus loin que Linq a adopté une syntaxe qui en est très proche.
2.2.3 Expressions arborescentes
Agir sur une source de données implique de pouvoir naviguer, disons, parmi les nœuds de sa
structure. La notion de relation entre des données stockées caractérise ceci au niveau conceptuel,
mais en pratique, qu’en est-il ? Pour des collections d’objets en mémoire, des itérateurs ou des
méthodes de saut à un autre élément sont généralement fournis par la collection elle-même. Pour
une structure relationnelle, les relations sont réalisées par des jointures entre plusieurs tables. Aucun
mécanisme orienté objet ne permet d’appeler une fonction qui sautera directement vers l’élément
désiré. Le problème est le même lorsqu’on manipule des données en Xml bien que, dans ce cas, la
syntaxe des requêtes soit plus proche du paradigme objet. Pour résoudre ce problème, les
expressions arborescentes (expression tree, en Anglais) ont vu le jour. L’intérêt n’est pas tant de
manipuler en soi la source de données mais plutôt de pouvoir naviguer dans un résultat et surtout
dans une requête. Comprendre la notion de jointure est indispensable pour écrire une requête qui y

fait appel et l’idée est ici que nous dotons notre programme orient objet d’un outil capable de
comprendre comment réaliser la navigation. Nous allons tenter de brièvement résumer son
fonctionnement.
Le concept des expressions arborescentes est dérivé de celui des expressions lambda. Premièrement,
une expression arborescente est une expression lambda dont le code va être maintenu en mémoire.
Deuxièmement, cette expression peut être parcourue lors de l’exécution. Troisièmement, elle devra
être compilée pour pouvoir être exécutée dans le langage propre à la source de données. Tentons
maintenant de faire le lien entre ces trois propriétés. Le code sera maintenu en mémoire pour
pouvoir être analysé pas à pas et modifié le cas échéant. L’expression devra être compilée, donc son
impact sur la source de données sera construit au moment de l’exécution. Il faut comprendre ici le
terme « compilé » comme signifiant « transformé dans le langage propre à la source de données et
optimisé pour plusieurs exécutions successives » 3 . La compilation classique, avec validation
syntaxique, a bien entendu toujours lieu. Par exemple, si la requête implique une lecture dans une
base de données relationnelle, la création de la requête Sql se fera à la volée. Une requête peut être
jugée comme étant syntaxiquement correcte sans avoir besoin de connaître la nature de la source de
données. Pour pouvoir être compilée, la requête doit disposer de son code en mémoire. Ce code sera
parcouru de manière à créer des instructions pour la source de données. Ces instructions se
composent de blocs logiques à la manière d’une équation mathématique. La longueur de ces
instructions n’est pas fixée et l’expression qui en représente une possède une structure en arbre,
d’où le terme d’expressions arborescentes. En résumé, cela revient à dire qu’une expression
arborescente représente un traitement générique (les paramètres sont fournis à l’exécution) et que
le code de cette expression est compilé à la volée, durant l’exécution du programme. L’intérêt est de
pouvoir construire des requêtes dont les paramètres seront fournis à l’exécution et de choisir quand
exécuter cette requête dans une optique d’optimisation. Cet aspect générique va permettre au
développeur d’écrire une requête Linq paramétrique et de choisir à quel moment et vers quelle cible
il décidera de l’exécuter. Cette requête pourra ainsi être traduite en une expression Sql si la source
de données est relationnelle ou au contraire en une requête XQuery à destination d’un fichier Xml.
Jusqu’ici rien n’a été cité pour justifier l’utilisation d’autre chose qu’une expression lambda adaptée.
En réalité, les possibilités offertes par les expressions lambda sont limitées lorsqu’un certain nombre
d’appels, récursifs ou non, sont nécessaires en leur sein. Considérons le code suivant (le code et
l’explication y afférante sont tirés de *1+):
fac => x => == 0 ? 1 : x * fac(x-1)
Ce code ne compilera pas tel quel, il est impossible d’appeler une expression lambda depuis sa
définition, ce que tente pourtant de faire l’appel « fac(x-1) ». Bien qu’il existe des techniques pour
palier à ce problème, nous n’allons pas les traiter ici. Le but était seulement de montrer avec un
exemple simple que les expressions lambda ne permettent pas de tout faire. Rappelons que les
expressions lambda sont utilisées par Linq pour représenter les clauses d’une requête. Mais certaines
clauses peuvent être arbitrairement complexes. Pensons par exemple à la possibilité de réaliser une
requête imbriquée dans une clause Where en Sql. Une simple expression lambda ne peut en ellemême
représenter une clause réalisant une requête imbriquée, cela l’obligerait à s’appeler elle-
3 Le terme compilé est traduit de l’Anglais « compiled » tel que mentionné dans *1+. L’explication fournie est en
revanche personnelle.

même durant sa définition. Les expressions arborescentes permettent de résoudre ce problème en
constituant une super expression composée de nœuds selon une structure en arbre. La construction
finale de l’expression se fait en commençant par les feuilles de l’arbre, en remontant ensuite.
L’ouvrage *1+ propose l’explication la plus claire qui a pu être trouvée sur la cuisine interne des
expressions arborescentes. Cette explication se base sur un exemple qui confronte une expression
lambda avec une expression arborescente, le code présenté ci-dessous est tiré de cet exemple. Nous
allons tenter de résumer cette explication afin de bien percevoir ce qu’est une expression
arborescente. Commençons donc par un code qui devrait permettre d’afficher le type d’une
expression lambda et celui d’une expression arborescente (certains extraits ont été traduits en
dehors de quoi le code est identique à celui proposé dans l’ouvrage) :
static void exemple()
{
Func lambdaInc = (x) => x + 1;
Expression exprInc;
exprInc = (x) => x + 1;
}
Console.WriteLine("avec expression lambda : {0}",
lambdaInc.ToString());
Console.WriteLine("avec expression arborescente : {0}",
exprInc.ToString());
Bien que la déclaration soit écrite de manière différente, le résultat est préssenti comme devant être
le même. Parlons maintenant du résultat non pas de ces deux expressions mais de l’affichage dans la
console. Le résultat produit par ce code prend cette forme :
Figure 2 : types d'expressions
Notre expression lambda est en fait une référence vers un type créé par le compilateur, le type « `2 »
prenant deux paramètres entiers. Notre expression arborescente quant à elle semble contenir la
structure de l’expression sous forme plus lisible. Rappelons-nous qu’une expression lambda est en
réalité une abréviation pour l’écriture d’un délégué. Le compilateur crée donc un objet délégué d’un
nouveau type, puisqu’une expression lambda fait usage du typage anonyme. Le type créé pour notre
expression arborescente n’est pas un délégué, comme nous pouvons le voir. Pour découvrir
comment est interprétée cette expression, [1] nous fournit le schéma page suivante ainsi que le code
correspondant à ce schéma.

Pour réaliser une structure similaire, voici le code proposé :
static void equivalent()
{
Expression exprInc;
}
ConstantExpression constante = Expression.Constant(1,
typeof(int));
ParameterExpression parametre =
Expression.Parameter(typeof(int), "x");
BinaryExpression addition = Expression.Add(parametre,
constante);
exprInc = Expression.Lambda(addition, new
ParameterExpression[] { parametre });
Console.WriteLine("ex. arb. avec syntaxe equivalente :");
Console.WriteLine("{0}", exprInc.ToString());
Et ce code produit le résultat que voici :
Figure 3 : schéma d'une expression arborescente
Figure 4 : type d'une expression arborescente
Notons que les quelques lignes qui apparaissent entre la déclaration de l’expression et l’affichage en
console, tout ce groupe représente l’équivalent de ce qui avait écrit la première fois comme
« exprInc = (x) => x + 1 ». Nous avons bien généré l’arbre en partant des feuilles, nœud par nœud.
Sans compliquer trop l’explication, signalons juste que chaque nœud est matérialisé par un objet
nœud de type générique, permettant d’assurer la navigation au sein de l’expression.

2.2.4 Extensions de méthode
« Extension de méthode » est le terme utilisé pour ajouter une méthode à une classe donnée sans
manipuler le code de cette classe. Cela reviendrait à créer une classe héritant de la classe de base en
spécifiant la ou les méthodes que l’on souhaite y ajouter. Plus qu’une facilité syntaxique, l’extension
de méthode permet d’éviter les pièges tendus par l’héritage et n’introduit pas de biais conceptuel
dans la programmation. Une extension de méthode ne peut utiliser que les champs publics de la
classe dont elle est l’extension. Elle doit elle-même être déclarée comme publique et statique. Son
premier paramètre doit être précédé du mot-clé this et le type de ce paramètre définit le type dont
la méthode est une extension. Le code suivant (tiré de [11]) montre une extension de méthode ayant
pour effet de représenter un nombre décimal sous forme de chaîne de caractères au format standard
US :
//Exemple fourni par Linq in Action
public static string FormattedUS( this decimal d) {
return String.Format( formatUS, "{0:#;0.00}", d);
}
L’utilisation des extensions de méthodes donnera peut-être l’impression de faire double emploi avec
les méthodes virtuelles mais il faut garder à l’esprit qu’une méthode virtuelle est résolue à
l’exécution alors qu’une extension de méthode doit être résolue dès la compilation. Précisons enfin
que le type étendu peut être générique, ce qui offre la possibilité d’étendre un ensemble de types
simultanément.
Typiquement, les extensions de méthodes sont utilisées lors de l’appel de clauses dans les requêtes
comme les clauses Where ou Select. Le framework .NET dans sa version 3 propose une interface
générique IEnumerable pour représenter toute donnée susceptible de faire l’objet d’une requête
ou d’une manipulation propre aux données. Des extensions de méthodes sont définies pour chaque
clause avec cette interface (ou l’un de ses descendants) comme type étendu.
2.2.5 Formalisme de requêtes
Cette sous-section s’inspire très fortement de *1+ et *11+. Les expressions de types requêtes ont été
introduites avec la troisième version du framework .NET et définissent la forme générale d’une
requête lorsqu’elle est écrite en C# ou en Visual Basic 2008. Une requête apparaît ici au sens large
puisque la syntaxe sera la même que ce soit une requête vers une base de données relationnelle,
vers une liste d’objets en mémoire ou encore vers un fichier XML. Une requête correctement
formulée doit commencer par une clause From et se terminer par une clause Select ou une clause
group. La clause From indique quels types d’objets vont être interrogés et ceux-ci doivent
implémenter l’interface IEnumerable représentant une collection de données générique
susceptible de faire l’objet d’une requête. Chaque clause de l’expression correspond à un ou
plusieurs appels d’extensions de méthodes pour l’interface citée précédemment. Voici un exemple
de requête typique :
var query = from e in etudiants
where e.moyenne >= 10
select e;
Le compilateur interprétera l’expression ci-dessus de la manière suivante :
var query = etudiants.Where(e => e.moyenne >= 10).Select(e => e);

A noter que etudiants n’a pas été particularisé et pourrait être aussi bien une classe représentant
une table de données relationnelle qu’une liste ordonnée d’objets en mémoire. Dans les deux cas, le
code écrit reste correct.
Les expressions de type requête sont traduites par le compilateur. La validité d’une requête et la
vérification des types sont établis lors de la phase de compilation du code. Les fautes de frappe et les
erreurs syntaxiques seront donc détectées par le compilateur, ce qui représente un avantage certain
par rapport aux accès Sql ou Xml qui ne révèleront leurs erreurs qu’à l’exécution.
Ceci permet déjà d’avoir une vue d’ensemble de Linq au travers des enrichissements syntaxiques
apportés par le framework version 3. Les expressions de type requête sont des interrogations
génériques qui appellent une succession de méthodes, chacune utilisant la réponse de la précédente
comme paramètre. Les méthodes d’extensions simplifient l’écriture de ces appels, les rendant plus
lisibles et plus faciles à implémenter. Les méthodes anonymes permettent la transmission des
paramètres d’un appel à l’autre. Les expressions lambda permettent de définir la logique de la
plupart des opérations effectuées par ces méthodes. Les types anonymes permettent de gérer en
mémoire les résultats de requêtes et l’inférence sur le typage est ce qui permet au compilateur de
faire le lien entre toutes ces fonctionnalités et de les valider à la compilation. Avant de rentrer dans
les détails de comment Linq est implémenté, deux remarques sont encore à souligner.
Premièrement, au vu des nouveautés syntaxiques du langage, Linq apparaît d’ores et déjà comme
une partie intégrante du langage et non comme un outil ORM 4 à greffer sur une architecture
existante. Cela implique qu’utiliser Linq ne nécessite que le fait de programmer avec une version
trois (ou supérieure) du framework .NET. L’autre point à soulever est que Linq n’est défini jusqu’ici
qu’en termes d’interface générique (IEnumerable pour rappel) et de mécanismes de langage. Ceci
implique deux choses : Linq est défini en plusieurs implémentations de base et il est possible
d’ajouter une implémentation de Linq pour s’adapter à un besoin précis.
Ceci termine notre tour d’horizon des changements généraux d’ordre purement syntaxique proposés
avec la troisième version du framework .NET. Nous avons introduit les principaux mécanismes qui
constituent Linq ainsi que leurs interactions, ayant souligné également que Linq se compose de
plusieurs implémentations. Nous allons de ce pas examiner ces différentes implémentations en
détails.
4 ORM signifie Object Relational Mapper. Il s’agit le plus souvent d’une désignation pour un utilitaire assurant
une certaine automatisation dans la réalisation du mapping objet relationnel.

Chapitre 3 : Implémentation Objets
Nous avons vu jusqu’ici quelle est la manière de formuler une requête syntaxiquement valide,
requête au sens de Linq. Rien n’a été spécifié en ce qui concerne la nature de la source de données,
ce qui implique que tout ce qui a été vu jusqu’ici sera toujours valable tant que nous parlons de Linq.
Mais Linq en lui-même n’est qu’un tas de concepts mis bout à bout. Si nous faisons le point de ce qui
a déjà été vu, nous avons un formalisme pour écrire des requêtes avec l’explication générale de
comment cette requête pourra être traduite vers une source de données, quelle qu’elle soit. C’est
précisément cette opération de traduction qui va nécessiter de connaître cette source plus en
détails. Pour répondre à cette attente, Linq est présenté avec une syntaxe unifiée, faisant abstraction
(répétons-le une fois encore) de la nature du stockage des données. Et pourtant, ce que nous
appelons Linq depuis le début est en réalité un ensemble d’implémentations partageant une même
syntaxe extérieure. Chaque implémentation est définie par un nom qui correspond au type de
données qu’elle cible. Ainsi nous parlerons de Linq to Sql, Linq to DataSet et ainsi de suite. Nous
commencerons notre étude par l’implémentation objet, Linq to Objects. Cette implémentation sera
rapidement parcourue, examinant quelques aspects intéressants. Parmi ces aspects, nous nous
intéresserons à certains opérateurs généraux (donc valables pour toutes les implémentations) et à
l’interface IEnumerable que doit implémenter toute donnée désirant interagir avec Linq. Ce
chapitre dans son ensemble est inspiré de [11] et de [1] pour la description des opérateurs.
3.1 Champ d’application
Linq to Objects permet d’interagir avec toute collection qui implémente IEnumerable. Les
collections standards intégrées au framework implémentent toutes cette interface, ce qui permet de
ne pas se poser la question dès lors qu’on utilise une structure de base. Pour ce qui est des
collections définies par l’utilisateur (le programmeur), le plus simple est de créer une collection par
héritage d’une structure standard. Cela peut s’avérer être une erreur conceptuelle dans certains cas,
et l’utilisateur devra réaliser lui-même l’implémentation de cette interface. Ceci s’applique à toutes
les implémentations Linq.
Regardons d’un peu plus près cette fameuse interface. Elle est définie dans l’espace de noms
System.Collections.Generic et la documentation 5 [4] montre que la seule méthode qui est renseignée
est GetEnumerator qui doit retourner un objet capable de parcourir les éléments de la collection un à
un. La documentation officielle fait également état d’un ensemble d’extensions de méthode qui
représentent en fait l’ensemble des opérateurs disponibles. Implémenter IEnumerable signifie
posséder les extensions de méthode nécessaires à Linq pour assurer le bon déroulement de requêtes
écrites avec la syntaxe vue précédemment. Nous allons maintenant nous intéresser à certains
opérateurs, ne pouvant tous les détailler par manque de place (il y en a plus d’une centaine en
comptant toutes les surcharges !).
5 La référence exacte est : http://msdn.microsoft.com/en-us/library/9eekhta0.aspx

3.2 Quelques opérateurs à la loupe
Les opérateurs représentent ce qu’il est possible de faire en utilisant Linq sur un ensemble de
données. Nous pouvons aisément nous imaginer qu’il est possible de réaliser une projection à la
manière d’un Select en Sql ou même un filtrage avec une clause Where puisque ces opérations sont
définies explicitement dans la syntaxe. Certaines fonctionnalités légèrement plus subtiles se sont
néanmoins glissées dans Linq et nous allons tâcher d’en rassembler quelques unes. Nous parlerons
ainsi de l’opérateur de projection groupée, de l’opérateur d’inversion, de l’opérateur de
groupement, des quantificateurs et de l’opérateur de conversion en énumérable.
3.2.1 Projection groupée
L’opérateur de projection groupée est appelé officiellement SelectMany. Son comportement est
globalement similaire à celui de l’opérateur Select, mais il a pour effet d’aplatir le résultat obtenu.
Ainsi, une requête demandant l’ensemble des cours suivis par les étudiants de dernière année
recevrait une réponse sous la forme d’une collection de cours et non comme une collection de
collections de cours. Lorsque seules les valeurs distinctes doivent être reprises, il suffit d’appliquer au
résultat l’opérateur Distinct. Il est intéressant de noter que l’aplatissement du résultat est disponible
mais non imposé au programmeur. S’il désire travailler sur les collections, un Select suffira. S’il désire
travailler sur les éléments eux-mêmes, un SelectMany constituera un raccourci appréciable.
3.2.2 Inversion et indexes
Les opérateurs de tri classiques que sont OrderBy et ThenBy permettent de trier les éléments d’un
résultat pour peu que ceux-ci implémentent l’interface IComparable. Mais en certaines
circonstances, il peut être intéressant d’avoir les derniers éléments de la liste. Pour ce faire, Linq
propose un opérateur d’inversion appelé Reverse qui retourne l’ordre des éléments au sein d’une
collection. Rien d’extraordinaire jusqu’ici mais il est nécessaire d’introduire un autre petit concept,
celui des opérateurs à index. Il faut savoir que plusieurs opérateurs acceptent un argument
supplémentaire de type entier et qui permet de ne considérer le résultat qu’après en avoir exclu un
nombre d’éléments correspondant à la valeur passée en argument. Avec cette information,
l’opérateur d’inversion permet d’inverser un résultat dont les x premières entrées ont été retirées ou
d’ignorer les x dernières entrées d’un résultat. Bien que cela puisse faire l’effet d’un simple gadget, il
est intéressant de noter cette combinaison d’opérateurs qui permet de réaliser une sélection plus
fine du résultat.
3.2.3 Groupement
L’opérateur de groupement, appelé GroupBy, réalise le groupement des résultats selon une clé
spécifiée. Une clause de groupement rend facultative la clause de projection (de sélection) car le
groupement renvoie le résultat sous forme d’une collection de collections, chaque collection étant
accessible par la valeur de sa clé associée. Le critère de groupement est défini par une expression
lambda ce qui rend le groupement très lisible. Notons que le critère de groupement n’est pas tenu de
faire partie de la clause de projection, comme c’est le cas en Sql. L’opérateur de groupement
possède plusieurs surcharges, permettant des réglages supplémentaires. Parmi ces surcharges, citons
la possibilité de préciser un sélecteur d’éléments ainsi qu’un sélecteur de résultat. Un exemple
d’utilisation se trouve à la page suivante.

var r = etudiants.GroupBy(
e => e.facultes,
e => new { e.nom, e.matricule },
(key, elements) => new {
Cle = key,
Nbr = elements.Count()} );
Le premier paramètre est le critère de groupement, le second est le sélecteur d’éléments qui va
jouer le rôle d’opérateur de projection embarqué. C’est ce paramètre qui va définir quelles valeurs
seront gardées lors de l’affichage du résultat. Le troisième paramètre est le sélecteur de résultat qui
permet de réaliser une projection non plus sur les éléments mais sur les groupes, ce qui est
particulièrement intéressant lorsqu’on souhaite obtenir des informations d’agrégation sur les
résultats sans le détail de ceux-ci. Le résultat produit par le code ci-dessus fournira des informations
sur nombre d’étudiants inscrits dans chaque faculté. Un groupement similaire mais sans le sélecteur
de résultat donnerait le nom et le matricule de chaque étudiant, ceux-ci étant groupés par faculté.
3.2.4 Quantificateurs
Les quantificateurs sont bien pratiques lorsqu’il s’agit de faire des manipulations complexes sur les
données. Les fameux « Pour tout » et « Il existe » sont d’ailleurs une légère entrave en Sql puisque
les quantificateurs universels n’y sont pas définis [12]. Linq fournit trois opérateurs de quantifications
Any, All et Contains. Le quantificateur Any retourne la valeur true si au moins un élément de la
collection sur laquelle il est appelé répond favorablement à l’expression lambda qui lui est passée en
paramètre. Si aucune expression ne lui est passée, il répond simplement à la question « Y a-t-il un
élément dans la collection ? ». Le quantificateur All permet de vérifier que l’ensemble des éléments
d’une collection vérifient un prédicat ayant la forme d’une expression lambda. En réalité cet
opérateur tente de vérifier qu’aucun élément de la collection ne vérifie pas le prédicat, ce qui signifie
qu’il retournera toujours true sur une collection vide. Le quantificateur Contains tente de vérifier si
une collection contient un élément spécifique. En termes objets, n’oublions pas que deux éléments
seront jugés identiques si et seulement si leurs références pointent toutes deux vers le même objet.
Il est néanmoins possible de fournir un comparateur personnalisé pour déterminer l’égalité de deux
objets sur base d’autres critères que leurs simples références.
3.2.5 Conversion en énumérable
Il s’agit ici d’un opérateur prenant en paramètre une séquence d’objets et cet opérateur retournera
des valeurs identiques mais sous forme d’objets énumérables, c’est-à-dire implémentant l’interface
IEnumerable. Comment s’y prend-il ? Très simplement, en utilisant un énumérable générique
dans lequel il encapsule les données de chaque élément. Cet énumérable générique est en fait une
collection assez pauvre puisque son seul but va être de fournir accès aux extensions de méthodes qui
caractérisent les énumérables. Toute autre information sera superflue puisque supposée déjà être
présente dans la collection à convertir. Notons qu’il existe d’autres opérateurs de conversion tels que
ToList, ToArray et ToDictionnary qui peuvent être utiles pour convertir un résultat dans un format
plus classique. L’opération de conversion en énumérable est fortement utilisé avec l’implémentation
Linq to DataSet, ceci sera développé dans la section consacrée à cette implémentation.

3.3 Exemple illustratif
Considérons un graphe d’objets représenté par une liste de listes. A titre d’exemple, imaginons que
les nœuds de ce graphe soient des villes et que chaque ville soit reliée par une route à une ou
plusieurs autres villes. Pour corser un peu la situation, nous allons doter nos villes d’informations
supplémentaires, un nombre d’habitants, un nom et une liste de toutes les communes qui
dépendent de celle-ci. Il faut bien sûr que chaque ville ait à sa disposition la liste des villes auxquelles
elle est connectée, cela constituera les branches de notre réseau. Le code comprenant les définitions
nécessaires à cet exemple se trouve en annexe (Annexe 1 : Code de l’exemple Linq to object).
Commençons par écrire une requête adressée au réseau et permettant de retrouver toutes les villes
comptant au plus 10000 habitants. Ceci s’écrit comme suit :
var petitesVilles = from v in reseauRoutier
where v.Hab = 2
&& c.Hab

Ceci produit le résultat suivant qui correspond bien à ce que nous attendions :
Figure 5 : exemple Linq to object
Les deux clauses From représentent en réalité l’équivalent d’une jointure. Les relations sont
accessibles de manière simple, il suffit d’avoir un accès à la propriété correspondante. Ceci permet
de justifier l’emploi de Linq même dans un contexte déjà « tout objet ». Linq représente un moyen à
la fois simple et puissant d’exprimer des requêtes. Nous avons vu en détails plusieurs opérateurs
ainsi qu’un exemple pratique mettant en scène l’implémentation objet de Linq. Nous allons
maintenant nous pencher sur les sources de données relationnelles.

Chapitre 4 : Implémentations relationnelles
La problématique de la persistance des objets remonte probablement à la popularisation des
premiers langages orientés objets [3]. Les applications utilisent des objets en mémoire pour décrire
le monde et ceux-ci disparaissent dès la fin de l’application. Pour les enregistrer, le recours à des
bases de données relationnelles reste une option plus que répandue [3]. Or le monde objet et celui
du relationnel ne s’interfacent pas parfaitement. Tout ceci n’est pas nouveau, bien sûr, mais pourtant
de nouvelles solutions à ce problème continuent de voir le jour à un rythme régulier. Linq se
présente comme l’une de ces solutions, voulant offrir une transition plus souple entre ces deux
mondes. Nous allons voir comment Linq a été pensé pour interagir avec les données relationnelles.
Nous commencerons par présenter quelques concepts à la base de la correspondance objetrelationnel
telle que réalisée par Linq. Nous détaillerons ensuite les différentes implémentations
relationnelles de Linq, en précisant leur moyen d’arriver à une correspondance entre objets et tables
relationnelles. Nous tâcherons également de soulever les avantages et limitations de chaque
implémentation. Après ces analyses, nous terminerons par un bilan global des possibilités offertes
par Linq pour manipuler des bases de données. Ce chapitre est inspiré de *3+ pour l’introduction.
Chaque section ayant été le fruit de recherches particulières, les références y seront détaillées au cas
par cas.
4.1 Entités en mémoire
Cette section est tiré de [1] et [11]. Interroger une base de données suppose d’avoir préalablement
établi un canal de communication ainsi qu’un langage commun. Linq ne permet pas d’écrire des
requêtes pour une base de données mais plutôt d’écrire des requêtes qui seront soumises aux objets
réalisant le mapping de la base de données. Il s’agit d’un mécanisme de cache où des objets
représentent l’état des données dans la base. Nous appellerons ces objets des entités et les
définitions de leur classe seront appelées des classes entités (ceci correspond à la nomenclature
utilisée dans l’ouvrage *1+). Cette notion est centrale et doit toujours être gardée à l’esprit : nous ne
pourrons jamais parler directement à la base de données. Chaque implémentation proposée par Linq
repose sur le concept des entités, bien que les solutions varient de l’une à l’autre, comme nous allons
le voir.
4.2 Linq to Sql
La première implémentation que nous allons étudier porte le nom officiel de « Linq to Sql » et nous
pourrions intuitivement penser qu’il s’agit de l’implémentation avec un grand « i » au regard des
bases de données relationnelles. Nous verrons que ce n’est pas le cas. Cette section contient
énormément d’informations tirées de *11+ pour les concepts théoriques, de *1+ et de *4+ pour
combler les vides laissés par [11]. Nous allons voir comment cette implémentation réalise le mapping
objet relationnel au niveau du code et quels sont les outils qui permettront de nous aider dans cette
tâche. Nous verrons quelles classes sont impliquées dans le mapping et quel est leur rôle, avec un cas
concret. Nous aborderons ensuite les possibilités de manipulation des données et les contraintes
associées. Nous terminerons l’étude de cette implémentation par un bref passage en revue des
pièges à éviter lors de l’usage de Linq to Sql.

4.2.1 Mapping
4.2.1.1Syntaxe au niveau du code
Commençons par une petite précision. Les cibles de Linq to Sql doivent implémenter l’interface
IQueryable qui est une descendante de IEnumerable. L’explication est simplement que
certaines possibilités disparaissent avec l’apparition des bases de données, comme par exemple la
notion d’ordre dans une table. Les opérateurs de sélection d’éléments permettant de choisir un
élément du résultat sur base d’un index n’ont plus de raison d’être. Des notions de synchronisations
entrent également en jeu, puisqu’il va falloir surveiller que nos entités n’aient pas fait l’objet d’une
modification dans la base de données. Pour asseoir ce changement de comportement (qui pourrait
entraîner des erreurs), c’est une autre interface qui définit les extensions de méthodes. Cette
précision faite, nous pouvons envisager la question du mapping.
L’assemblage System.Data.Linq permet d’utiliser les classes entités dans le code. Ici, l’esprit général
des entités est de concevoir une classe entité comme la représentation d’une table dans la base de
données. Cette représentation doit être explicitement renseignée dans la définition d’une classe, au
moyen du mot clé « Table » suivi par l’expression « (Name= « NomDeLaTable ») », le tout, entre
crochets, placé juste avant l’identificateur de la classe. Chaque propriété de la classe représentant un
attribut de la table doit être précédée par le mot clé « Column » entre crochets également. Lorsque
le nom de la propriété est différent de celui de l’attribut, une expression « Name » similaire à celle de
la table doit être utilisée. Voici l’exemple d’une classe entité (cet exemple s’appuie sur *11+ et *1+) :
[Table(Name="Clients")]
public partial class Class1
{
[Column] private string IDClient;
[Column(Name="Nom")]private string _champ2;
}
Cette classe est une correspondance de la table Clients de la base de données, table qui possède
dans ses attributs au moins un champ « IDClient » et un champ « Nom ». Une classe entité n’est pas
tenue d’effectuer le mapping de chaque attribut de la table. Elle peut également contenir des
attributs ou propriétés qui lui sont propres et qui ne participent pas au mapping. Il s’agit ici de
considérations syntaxiques mais comment le mapping est-il réellement effectué ? Nous n’avons
spécifié aucune information qui pourrait permettre d’identifier la base de données, nous avons
seulement fait « l’autre moitié » du mapping. En effet, nous avons renseigné qu’une classe Class1 est
une classe entité et que certaines de ses propriétés sont en correspondance directe avec des
attributs relationnels. Jetons maintenant un coup d’œil sur l’autre facette de ce mapping.
4.2.1.2 Principes et fonctionnement
La correspondance est réalisée au moyen de fichiers spécifiques pouvant être de deux formats : le
format Dbml (pour DataBase Markup Language) et le format Xml. Commençons par parler du format
Dbml qui est considéré comme principal pour Linq to Sql. Le format Dbml est un langage à balises
tout comme le Xml dont il est dérivé. Une définition de ce schéma est disponible avec Visual Studio
2008, cette définition servant de validateur intégré. Dans un fichier Dbml représentant un mapping
valide, les premières lignes fournissent tout un tas de renseignements généraux comme la chaîne de
connexion à la base de données et le nom de la classe utilisée comme DataContext. Nous reparlerons
plus amplement du DataContext dans une section ultérieure, considérons pour l’instant cette classe

comme gestionnaire des objets entités. Viennent ensuite les définitions des tables relationnelles et
les classes entités qui leur correspondent. Les procédures stockées et les fonctions utilisateurs de la
base de données sont également renseignées à cet endroit. Pour chaque table, les attributs et leurs
propriétés Sql sont renseignés. En plus des propriétés purement relationnelles, des informations de
synchronisation sont fournies, comme IsDbGenerated dans l’exemple ci-dessous. Ceci touche en
particulier à la synchronisation qui sera abordée lorsque nous aborderons les cas pratiques de
mapping. Voici un extrait d’un fichier Dbml 6 :
Lorsque le DataContext approprié est instancié, le fichier Dbml fournit toutes les informations
nécessaires à la correspondance entre les mondes objet et relationnel. Le lien entre ces deux fichiers
est très simple : le DataContext possède des références vers les classes entités, elles-mêmes validées
par le Dbml du même nom que le DataContext 7 . Il faut savoir que le format Dbml est le format le
plus riche en termes d’informations incluses dans le mapping mais il n’est pas le seul disponible. Il a
été prévu qu’un fichier Xml puisse servir de source externe de mapping, le terme « externe » est le
terme officiel utilisé par Microsoft (dans la documentation) et désigne le fait que en interne ce sera
toujours un fichier Dbml qui sera manipulé même s’il pourra être créé depuis une source en Xml. Les
informations fournies par un tel fichier Xml sont sensiblement moins fines que celles d’un fichier
Dbml. En effet, les informations générales sur les tables et les entités sont présentes dans les deux
6 L’alignement des balises laisse ici quelque peu à désirer, ceci étant du au manque de place.
7 nomDataContext hérite de DataContexte et nom.dbml est le fichier de mapping.

cas, mais certaines informations concernant la synchronisation des entités en mémoire ne peuvent
pas être exprimées. Nous n’allons pas approfondir ces détails dans le cadre de cette étude, signalons
simplement que ces deux formes de mappings sont équivalentes, l’une étant moins expressive que
l’autre (des réglages supplémentaires seront à la charge du programmeur s’il décide d’utiliser cette
méthode).
4.2.1.3 Gestion par le DataContext
A ce stade, nous sommes en droit de poser la question suivante « Quand et Comment seront
instantiées ces classes entités ? ». L’idée est que ces objets ne seront créés que lorsqu’ils seront
nécessaires afin de ne pas encombrer la mémoire et une classe en particulier sera responsable de
leur gestion. Cette classe sera en quelque sorte le « chef d’orchestre » du mapping, il s’agit de la
classe DataContext.
Un objet de classe DataContext représente le lien entre la base de données et les classes entités qui
lui sont assignées. Un DataContext contient une ou plusieurs classes entités et est responsable de la
génération du code Sql qui sera envoyé à la base de données. C’est toujours le DataContext qui va
maintenir les entités, au besoin les créer et les mettre à jour. En pratique, la classe DataContext est le
plus souvent dérivée et c’est un de ses descendants qui est utilisé [1], la raison en deviendra
apparente lorsque nous envisagerons notre cas pratique. Quand est-ce que les objets entités seront
instanciés ? Lorsque le DataContext reçoit une requête, s’il n’a pas les entités nécessaires à la
fabrication de la réponse, il va soumettre la requête à la base de données en créant les entités
correspondantes. Nous devons attirer l’attention sur le terme « reçoit » qui est laissé expréssément
flou. Linq to Sql utilise une méthode d’exécution différée (deferred loading en Anglais) pour ses
requêtes. Cela signifie que lorsqu’une requête est soumise au DataContext, celui-ci ne va pas
nécessairement la transmettre directement à la base de données 8 . Par contre, une provision
d’entités sera créée pour pouvoir accélérer leur chargement le moment venu. Bien que cela puisse
apparaître comme un mécanisme tordu, cela prend son sens dans un contexte où les accès à la base
de données sont nombreux et éventuellement concurrentiels. Une politique d’optimisation complexe
est déployée par Linq mais nous en reparlerons plus tard. Nous avons vu jusqu’ici le rôle d’un
DataContext vis-à-vis des entités, tant celles qui se trouvent en mémoire que celles qui séjournent
dans les tables relationnelles. Nous verrons plus loin comment la théorie du mapping est mise en
pratique et quel y est le rôle du DataContext.
8 Il s’agit là d’une interprétation de diverses sources contradictoires. *11+ précise que chaque appel au
DataContexte entraîne une réaction vers la base de données, sans préciser sa nature. [4] reste très flou. [1] dit
clairement que pour une lecture, l’interaction n’est pas initiée par le programmeur.

4.2.2 Opérations fondamentales
Nous allons explorer dans cette sous-section les procédures dites CUD (Create Update Delete) et
comment elles sont traduites vers les habituelles instructions Sql INSERT, UPDATE et DELETE. Nous
examinerons en priorité les mécanismes sous-jacents et comment ceux-ci font pour surveiller les
éventuels changements dans les entités. Chacune des opérations sera ensuite analysée pour avoir
une idée globale de la gestion des entités vis-à-vis du support relationnel en arrière-plan. De
nombreuses informations apparaissant ici sont directement tirées de [4], des sources non officielles
[13] ont contribué à éclaircir les points obscurs.
Pour pouvoir considérer des entités et leur évolution, il faut pouvoir agir sur ces entités et disposer
d’un système capable de gérer ces modifications. Nous allons commencer par nous intéresser à ce
dernier. Pour Linq to Sql, ce système porte le nom de « change tracking service » que nous
appellerons le service sentinelle bien que ceci ne constitue en aucun cas une appellation officielle.
Cette sentinelle est chargée de conserver les états originaux des entités de manière à pouvoir
détecter les changements. L’autre fonction de cette sentinelle est de pouvoir recréer les
modifications observées en termes d’instructions Sql, pour éviter de systématiquement inclure les
valeurs de tous les attributs d’une entité [4]. Le service sentinelle a recours à un système de
marquage pour identifier les entités modifiées. Les marques désignent l’état courant de l’entité,
l’état par défaut étant « non modifiée ». Des états comme « à insérer », « à supprimer » ou « à
mettre à jour » permettent de rapidement savoir quelle modification a été apportée à l’entité. Le
service sentinelle est accessible depuis le DataContext via l’appel de la méthode GetChangeSet [1]. La
sentinelle est active en permanence et collecte le moindre changement survenu sur une entité.
Lorsque le DataContext reçoit l’instruction d’exécuter les modifications faites jusqu’alors, le service
sentinelle vérifie l’état de toutes les entités en mémoire et créer le code Sql nécessaire pour obtenir
les mêmes modifications dans la base de données.
Les ajouts et suppressions d’entités se font de manière relativement similaire, nous allons donc les
examiner ensemble. Ajouter une entité se fait de la même manière qu’un ajout de n’importe quel
type d’objets, par un appel au constructeur. La suppression d’une entité implique de l’avoir
préalablement isolée, autrement dit d’avoir en main l’objet entité en question. Pour l’une ou l’autre
de ces opérations, il suffit désormais d’appliquer les changements au DataContext en marquant
l’entité à modifier. Marquer une entité « à insérer » se fait en appelant InsertOnSubmit sur le
DataContext en passant en paramètre une référence vers l’entité à marquer. Pour réaliser la même
chose lors d’une suppression, il faut utiliser DeleteOnSubmit, toujours en passant la référence
adéquate en paramètre. A noter qu’une version a été développée pour chacune de ces méthodes de
manière à opérer en une fois l’opération sur une collection d’entités. Ces versions groupées sont
appelées InsertAllOnSubmit et DeleteAllOnSubmit respectivement. Ces variantes groupées ne sont là
que dans le but simplifier l’écriture, aucune forme d’optimisation par groupement n’a lieu 9 .
La mise à jour d’une entité est légèrement différente. Elle nécessite d’avoir isolé l’entité et d’avoir
changé la valeur d’au moins une de ses propriétés. Linq to Sql n’autorise pas la modification de la
propriété renseignée comme étant la clé primaire. Ceci pourrait être intéressant lorsqu’on souhaite
remplacer une entité par une autre en prenant en compte la participation à des relations entre
entités. Une mise à jour de ce type se fait par insertion de la nouvelle valeur et remplacement de
9 Ceci a été vérifié en rebasculant le log d’écriture Sql vers Console.out : y défile une longue suite de requêtes
Sql indépendantes.

l’ancienne valeur dans chaque relation à laquelle elle participe. Notons également que les mises à
jour sont les seules opérations pouvant être invisibles au programmeur inattentif. Dans le cadre
d’une relation entre entités, s’il l’un des participants est supprimé l’autre subira une mise à jour pour
refléter que cette relation n’existe plus [4] [11]. Cette mise à jour n’aura éventuellement pas été
spécifiée explicitement. De même, lorsqu’une association est créée en passant à une entité une
référence vers une autre entité, l’entité reliée (mais non modifiée explicitement) sera mise à jour.
Ajouter ou modifier une entité du DataContext n’est en soi que la moitié du travail. Les entités en
mémoire ne sont plus synchronisées par rapport à la base de données et les modifications désirées
n’y seront pas encore effectives [1]. Pour notifier le DataContext qu’une mise à jour est souhaitée, il
faut le faire explicitement par le biais de la méthode SubmitChanges. Cette opération va prendre en
charge toutes les modifications apportées aux entités, qu’il s’agisse de créations, de mises à jour ou
de suppressions. C’est lors de l’appel de cette méthode que le service sentinelle va répertorier toutes
les modifications apportées aux entités. Des instructions Sql vont ensuite être générées pour amener
la base de données correspondant aux entités en mémoire. Ceci a plusieurs implications en termes
de performances et d’ordonnancement des opérations. Premièrement, chaque appel de la méthode
SubmitChanges peut potentiellement donner lieu à des opérations inattendues à cet instant précis
[4]. En effet, la sentinelle enregistre toutes les modifications et il est tout à fait possible qu’une autre
partie du programme ait créé des modifications entre une insertion et sa soumission quelques lignes
plus loin. Dans un contexte multithreads ou dans celui d’une programmation par événements,
l’enchaînement exact de chaque instruction est au mieux dur à prévoir. Les mises à jour implicites
sont également à ranger dans cette catégorie d’opérations fantômes. Deuxième remarque à
soulever, le service sentinelle passe en revue chaque entité en mémoire à chaque appel de cette
fameuse méthode. La seule opération effectuée sur une entité non modifiée consiste à tester si son
marquage est toujours égal à « non modifiée ». Pour un ensemble conséquent d’entités, ceci peut
créer un délai non désiré dont il faut rester conscient. Il est, par exemple, conseillé d’éviter d’appeler
SubmitChanges dans une boucle destinée à créer un ensemble d’objets.
4.2.3 Cas pratiques
Il nous reste maintenant à découvrir les techniques pratiques pour construire un mapping et son
DataContext associé. Nous allons ensuite soumettre quelques requêtes et observer comment nous
parviennent les résultats. Nous envisagerons d’abord un cas très simple à vocation illustrative avant
de considérer des scénarios plus complexes.
Supposons que nous ayons une base de données Sql Server 2008 pleinement fonctionnelle à notre
disposition et que notre application ne souhaite pas prendre en charge les accès concurrentiels pour
l’instant. Nous allons réaliser tout cela avec Visual Studio 2008, étape par étape.
En ayant créé un nouveau projet C#, nous allons ouvrir l’explorateur de serveurs pour y localiser
notre base de données. Lorsque nous l’avons trouvée, nous pouvons désormais voir les tables qu’elle
contient, ses procédures stockées, ses fonctions utilisateurs, les associations entre les tables et de
nombreuses autres informations dont nous ne ferons pas usage dans ce simple petit test. Ajoutons
une classe à notre projet dont le type sera « Linq to Sql class ». Les classes Linq to Sql arborent
l’extension Dbml, aussi nous pouvons en conclure qu’il s’agira de notre fichier de mapping.
Choisissons lui un nom de circonstance (par exemple « MonMapping ») et validons notre choix afin
de créer ce fameux fichier de mapping. Rappelons que la structure d’un tel fichier, vue à la section

précédente, est assez complexe et semble assez rébarbative à établir. Aller vérifier chacune des
nombreuses propriétés de chaque attribut d’une table, pour toutes les tables impliquées dans le
mapping, cela semble totalement rebutant. Et bien, réjouissons-nous, cela n’a pas à être fait. En
effet, à la création de notre classe à l’extension Dbml, Visual Studio nous présente un éditeur
graphique où nous pouvons, à notre convenance, créer des entités depuis la base de données ou de
toutes pièces pour les ajouter dans le futur. Créer une classe entité depuis la base de données, cela
signifie faire du « glisser-déplacer » depuis l’explorateur de serveurs vers l’espace d’édition
graphique. Toutes les métadonnées sont automatiquement extraites depuis les tables concernées,
mettant directement à jour le fichier Dbml. Ajoutons deux tables à celui-ci. Si nous consultons le
fichier Dbml, nous pouvons y trouver désormais la définition d’une classe nommée
MonMappingDataContext héritant de DataContext et des deux classes entités que nous avons créées
par « glisser-déplacer ». La génération des informations de mapping ainsi que celle de notre classe
héritant de DataContext. Voici pourquoi nous avions dit plus haut qu’en pratique c’est une classe
dérivée qui est utilisée. Cela nous permet également de définir plusieurs contextes et mappings
différents si tel est notre bon vouloir. De retour à notre exemple, nous pouvons à présent écrire des
requêtes pour nos nouvelles classes entités, le compilateur aura à sa disposition toutes les
informations nécessaires pour juger de la validité syntaxique de cette requête. C’est ce que nous
allons faire.
MonMappingDataContext db = new MonMappingDataContext();
var query = from c in db.demo_customer
//clause where eventuelle
select c.customer_name;
Console.WriteLine("Voici la table demo_customer :");
foreach (var q in query)
{
Console.WriteLine(q);
}
En exécutant ce code sur le mapping considéré précédemment (nommé MonMapping), nous
retrouvons notre DataContext ainsi que la structure des expressions de requêtes. Notons la simplicité
d’utilisation : le mapping a été créé de manière presqu’entièrement automatique, une ligne pour
instancier notre DataContext, deux lignes pour notre requête et l’affaire est faite. Nous avons par
ailleurs la sécurité de la validation par le compilateur, aucun code « unchecked » n’est utilisé.
Procédons maintenant à une insertion et à une suppression. Le code correspondant à ces opérations
est le suivant :
Console.WriteLine("Ajoutons un nouveau client avec Linq");
demo_customer dc = new demo_customer();
dc.customer_name = "nouveau client";
db.demo_customer.InsertOnSubmit(dc);
db.SubmitChanges();
Console.ReadLine();
Console.WriteLine("Voici la nouvelle table demo_customer :");
foreach (var q2 in query)
{

}
Console.WriteLine(q2);
Console.WriteLine("Supprimons le nouvel ajout");
db.demo_customer.DeleteOnSubmit(dc);
db.SubmitChanges();
Console.ReadLine();
Console.WriteLine("Regardons a nouveau la table demo_customer :");
var query2 = from c in db.demo_customer
select new { c.customer_id, c.customer_name };
foreach (var q3 in query2)
{
Console.WriteLine(q3);
}
Console.ReadLine();
Et le résultat de l’ensemble de ce code est le suivant :
Figure 6 : requêtes Linq to Sql
Tout cela paraît bien simple et automatisation rime souvent avec perte de contrôle sur les
mécanismes sous-jacents. En effet, revenons à nos hypothèses de départ, à savoir que nous ayons
accès à une base de données Sql Server 2008 pleinement opérationnelle et que nous ne nous
préoccupions pas des accès concurrentiels. Dans la pratique, il est tout à fait possible que nous ayons
affaire à une base de données dont la structure soit connue mais sans l’avoir à disposition. De même,
nous serions bien imprudents en affirmant qu’un projet quelconque utilisera une base de données
Sql Server 2008. Bon, et qu’est-ce que cela change pour nous si nous n’avons pas la base de données
sous la main ? Et bien, l’extraction automatique des métadonnées se glisse hors de notre portée et
nous devrons trouver un moyen d’obtenir la structure de la base de données. Rappelons que le

mapping peut-être effectué par un fichier Dbml ou Xml, qui sont globalement des fichiers textes et
donc, faciles à échanger via le réseau car de taille modeste. Visual Studio 2008 offre la possibilité
d’extraire facilement un fichier Dbml depuis une base de données, ne reste alors plus qu’à le rendre
disponible via un service web ou un procédé semblable. D’accord, mais que se passera-t-il si notre
base de données n’est pas (ou n’est plus) du type Sql Server 2008 ? La réponse va paraître brutale,
cela ne marchera tout simplement pas, Linq to Sql est prévu pour être utilisé uniquement avec Sql
Server. Attention, il est question ici de « Linq to Sql » et rappelons nous qu’il ne s’agit que d’une
implémentation Linq et non de « Linq vers relationnel » dans son ensemble. Plus qu’un tour de
passe-passe linguistique, il s’agit de deux choses différentes. Linq to Sql peut être vu comme un
raccourci simplifié pour les utilisateurs de Sql Server alors que les autres variantes de Linq offrent
d’autres possibilités pour relier le monde relationnel et celui des objets. Nous détaillerons ces autres
possibilités dans les sections qui leur sont dédiées.
4.2.4 Erreurs et difficultés
Pour terminer l’analyse pratique de Linq to Sql, nous allons envisager deux cas plus complexes mais
néanmoins tout à fait plausibles. Tout d’abord le cas où nous n’avons tout simplement pas de base
de données, il arrive pour certains projets de devoir créer leur base de données « from scratch ».
Nous allons voir quelle aide Linq peut apporter dans ce contexte et quelles en sont les inconvénients.
Nous allons ensuite examiner la gestion des accès concurrentiels et les diverses erreurs considérées
comme typiques. Cette sous-section est tirée de [1], plus particulièrement du chapitre 5 : Managing
Sql Data.
Dans le cas où nous n’avons pas encore de base de données, nous pouvons soit la créer de manière
classique, soit utiliser Linq pour le faire. Rappelons-nous lors de notre premier test, nous avions à
notre disposition une boîte à outil fournie par Visual Studio. Cette boîte à outil porte en réalité le
nom de « Object Relational Designer » ou Concepteur Objet Relationnel pour rester dans la langue
de Molière. Ce concepteur nous permet de définir de nouvelles entités, sans nous préoccuper des
données relationnelles existantes (c’est-à-dire que cette possibilité est disponible même si la
génération des entités depuis une base de données a été utilisée). Ces entités ne correspondant à
aucune table relationnelle, elles sont inutilisables telles quelles. Néanmoins une instance d’un
DataContext peut créer une base de données depuis son schéma de mapping en faisant appel à la
fonction CreateDatabase définie pour la classe DataContext. L’ouvrage [1] nous met en garde contre
une telle pratique, précisant que ce n’est à utiliser que lorsque les classes entités sont jugées plus
importantes que la structure relationnelle. En effet, le passage d’une base de données à un fichier
Dbml n’est pas parfaitement bidirectionnel et certaines opérations ne sont pas possibles comme par
exemple la création de procédures stockées ou de triggers. Autrement dit, nous pouvons utiliser
cette méthode lorsque la base de données est utiliser pour servir l’application et non le contraire,
auquel cas nous devrions créer notre base de données avec du code Sql. Cela reste très intéressant
car nous pouvons désormais réaliser la persistance d’objets sans devoir écrire la moindre ligne de
code Sql et nous pouvons profiter de la validation des requêtes à la compilation, ce qui simplifie les
tests et réduit le temps de développement.
Les bases de données sont énormément utilisées dans le monde du web. Cet environnement à la
particularité de pouvoir provoquer des accès concurrentiels n’importe quand. Profitons de passage
pour préciser ce que nous entendons par « accès concurrentiels ». Nous allons parler ici d’accès
concurrentiels pour désigner les problématiques différentes que sont les opérations concourantes

sur des données (typiquement demande de lecture d’une donnée en cours de modification ou à
modifier), les transactions (avec mécanismes de roll-back si satisfaire la transaction s’avère
impossible) et la gestion des exceptions Sql [12]. Dans ces trois domaines, la presque totalité des
problèmes pouvant survenir sont découverts à l’exécution, ce qui est toujours gênant lorsqu’on
souhaite offrir un accès en ligne aux ressources. Linq manipule les objets entités en mémoire et donc
crée un délai supplémentaire durant lequel des accès concurrentiels peuvent apparaître. Un objet
entité contient plusieurs indicateurs permettant de savoir s’il correspond ou non à son homologue en
base de données et le DataContext peut donc détecter lorsqu’un conflit survient. Il est possible
d’assigner une politique de gestion de conflits plus ou moins fine selon ce qui est désiré. Nous
n’allons pas trop nous étendre là-dessus, les heuristiques de résolution de tels conflits dépassent
largement le cadre de ce travail. Nous nous contenterons de dire que les opérations concourantes
ont été envisagées et que le DataContext est en mesure de réaliser une gestion de conflits assez
performantes pour peu qu’une politique adaptée lui soit fournie. Les informations de
synchronisations jouent également un rôle important à ce niveau. En effet, lorsque le comportement
est laissé par défaut (il s’agit du IsDbGenerated), le DataContext ira régulièrement s’informer auprès
de la base de données pour s’enquérir d’éventuels changements survenus pour chaque attribut
ayant ce comportement. Le comportement inverse est également possible. Lorsqu’une entité doit
modifier l’une de ses propriétés, elle en avertit le DataContext et celui-ci va marquer l’entité avec le
statut « modifié » le temps de répercuter les changements dans la base de données. Cela nous laisse
déjà entrevoir les possibilités de conflits engendrés par des opérations concourantes. Microsoft, par
le biais de la bibliothèque en ligne MSDN [4], propose plusieurs politiques de gestion de conflits mais,
comme dit plus haut, tout cela dépasse le cadre de notre étude.
Les transactions sont utilisées systématiquement par les objets de type DataContext. Cela n’a rien
d’étrange quand nous avons vu que le DataContext est l’unique lien entre la base de données et
l’ensemble des entités qui lui sont associées. Lorsque le DataContext se voit soumettre une ou
plusieurs requêtes, il effectue en priorité les changements sur les entités en mémoire et va, selon la
disponibilité de la connexion à la base de données, soumettre à son tour les changements à la base
de données. Chaque requête soumise au DataContext est encapsulée dans une transaction au sens
relationnel du terme. Il est néanmoins possible pour le programmeur d’élargir une transaction, en y
ajoutant des modifications. La classe TransactionScope (disponible dans la bibliothèque
System.Transactions) permet cette opération le plus naturellement qui soit [4]. Il suffit d’instancier
un nouvel objet TransactionScope sans paramètre et d’y inclure l’ensemble des opérations
souhaitées, comme le montre le morceau de code suivant :
using (TransactionScope ts = new TransactionScope())
{
monDataContext.SubmitChanges();
//Soumission de l'ensemble des requêtes en attente
}
//... code supplémentaire éventuel
ts.Complete();
Nous avons encore à aborder le problème des exceptions. Les auteurs de « Programming Linq » [1]
nous présentent trois sources principales d’exceptions, la création d’un DataContext, les accès à une
base données en lecture et ceux en écriture. Notons que Linq ne possède pas d’exceptions qui lui

sont propres. La plupart des exceptions classiques peuvent être rencontrées en utilisant « Linq to
Sql » néanmoins nous n’allons détailler que celles qui sont typiques de son utilisation.
Les erreurs susceptibles d’apparaître lors de la création d’un DataContext sont du type
InvalidOperationException et indiquent un problème au niveau du mapping. De par leur nature, ces
exceptions « sont considérées comme étant irrécupérables ( « unrecoverable » ) la plupart du
temps » [1]. Ce genre d’erreurs est « très peu probable si le mapping est généré automatiquement »
[1].
Lors de l’accès en lecture à une base de données, plusieurs types de problèmes peuvent survenir :
l’accès peut être impossible, refusé, la structure des tables peut être différente de ce qui était prévu
et ainsi de suite avec la presque totalité des problèmes pouvant survenir lors de l’accès à une base de
données relationnelle. Le principal problème avec l’accès en lecture est qu’il est impossible de
prévoir quand il aura lieu exactement. En effet, nous avions vu dans les précédentes sections que
Linq to Sql ne permettait de parler directement qu’au DataContext (c’est-à-dire aux représentations
en mémoire que sont les entités) et jamais à la base de données. Et pire encore, le DataContext va
lui-même effectuer le travail en arrière-plan (groupement de requêtes et analyses pour maintenir la
synchronisation principalement) responsable d’avoir déclenché l’exception sans que vous puissiez
avoir directement connaissance de la nature de ces menues opérations ni du moment précis où elles
auront lieu. En imaginant une application multi tiers, les causes d’erreur sur les accès à la base de
données peuvent se retrouvés en de nombreux points (nous parlons seulement ici des accès en
lecture, rappelons-le). Nous pourrons toutefois nous consoler en constatant que la plupart des
erreurs courantes auront été détectées dès la compilation et la syntaxe Sql, véritable nid à problèmes
pour le développeur orienté objet, est l’affaire du DataContext et non celle du programmeur
désormais.
Les accès en écriture ont lieu quant à eux à des moments relativement contrôlés. A ces instants, le
DataContext répercute toutes les modifications apportées aux entités sur la base de données. Du fait
de cette écriture décalée et d’éventuelles opérations concourantes, nous devons envisager la
possibilité que des opérations inattendues aient lieu à chaque écriture. Ceci veut dire qu’une écriture
est susceptible de déclencher n’importe quel type d’exception Sql [11][1][4]. Ceci rejoint grandement
le problème des opérations concourantes et de la mise en place d’une gestion de conflits. Nous
devions cependant souligner le fait que d’autres erreurs peuvent survenir lors de la phase d’écriture.
C’est le cas des violations de contraintes d’intégrité, des dépassements de délais lors de l’attente
d’une réponse et ainsi de suite, la liste étant longue. Linq to Sql ne propose aucun remède miracle
contre l’apparition de ces exceptions et elles doivent être gérées comme dans le cadre d’un accès
relationnel classique.

4.2.5 Performances
Les questions de performance sont toujours à garder à l’œil lorsque mapping il y a. En effet, le
mapping n’est jamais qu’une ou plusieurs couches insérées dans une pile parfois déjà conséquente.
La performance n’est pas toujours facile à cerner, en revanche. Nous pouvons d’ores et déjà parler
de performances exprimées en temps développeurs car nous avons vu ce qu’il en était de la syntaxe
et de la simplicité de mise en œuvre. Le travail est plus rapide et moins porteur d’erreurs ([1] utilise
les termes de « less error prone » pour désigner le développement avec Linq to Sql). Si le temps de
mise en œuvre est réduit par rapport à une approche ADO.NET qu’en est-il de la qualité ? Les codes
auto-générés sont souvent pointés du doigt dans ce domaine. Et les temps de réponses, seront-ils
satisfaisant ? Nous allons réaliser plusieurs tests afin de nous forger notre propre opinion.
4.2.5.1 Test d’insertions
Nous allons ici envisager un scénario très simple, à savoir une succession d’insertions dans une table
relationnelle vierge. Nous mettrons en compétition une version Linq to Sql avec une version
ADO.NET. Les requêtes seront groupées ainsi que le ferait une application avec base de données
locale, dans un but de réduction du nombre d’accès disques. La situation est exprimée ci-dessous en
pseudo code :
DateTime star t = now ; //start pour le test 1
for(int i=1 ; i < nbrOps ; ++i)
{
requete.ajout(insertion unitaire);
}
requete.Execute() ;
DateTime end = now ; //Ecart = end – start
Les codes utilisés lors de ce test sont disponibles en annexe (Annexe 2 : codes de tests de
performances pour Linq to Sql). Après plusieurs exécutions de la version Linq pour un même nombre
d’opérations, un phénomène curieux apparaît. Cette version est plus lente à la première exécution
du test, et les temps de réponses se stabilisent dès la deuxième exécution du test. C’est assez
inattendu et rien, à ce stade de notre étude, ne semble pouvoir justifier cela. [1] nous apprend que le
DataContext rassemble toutes les informations nécessaires au mapping lors de sa première
utilisation. Le mapping est gardé en mémoire jusqu’à son remplacement par un autre mapping ou
jusqu’à la fermeture de Visual Studio. Le gain de temps observé varie entre quelques dixièmes à deux
secondes, quel que soit le nombre d’opérations demandées par la suite. Pour revenir à notre test,
nous pouvons désormais comparer la version ADO.NET aux deux temps de réponse de la version
Linq. De manière surprenante, la version Linq a été observée comme étant plus rapide pour ses deux
temps de réponse. Ceci semble aller contre toute la logique du mapping et en réalité, c’est là qu’un
examen plus approfondi du code permettra de dénicher l’astuce. Pour ce premier test, la version
ADO.NET a été construite de manière très naïve. La requête étant représenté par un string, celui-ci
est modifié à chaque tour de boucle pour représenter une requête de plus en plus longue. La
manipulation de ce string en mémoire va entraîner un nombre d’opérations responsables de
l’accumulation de ce retard. Notons déjà ici une des forces de Linq to Sql qui est de réaliser
l’optimisation pour le programmeur alors que la version ADO.NET peut fonctionner en étant très mal
programmée. En ne considérant que les temps d’accès à la base de données, la version ADO.NET
s’est montrée plus rapide, ce qui était beaucoup plus prévisible. Le temps d’exécution nécessaire
varie presque du simple au double entre les deux approches dans ces conditions. Ces temps varient
linéairement avec le nombre d’opérations à effectuer. L’ergonomie et la productivité du développeur

Linq se paient par une hausse conséquente des temps d’accès (ceci est confirmé par [11] et [1]). Le
graphique ci-dessous montre les résultats moyens observés durant les deux précédents tests. L’axe
des ordonnées représente les temps moyen d’exécution exprimés en millisecondes, alors que les
abscisses représentent le nombre d’opérations d’insertion successives effectuées durant le test. Les
courbes suivies de la mention « (with Q) » désignent les résultats du premier test, où le temps
d’exécution comprend également le temps nécessaire à la construction de la requête. Pour les
courbes qui ne sont pas suivies par cette mention, il s’agit des résultats obtenus lors du second test
où le temps d’exécution considéré ne comprend que le temps nécessaire à la connexion directe à la
base de données. Voici la situation exprimée en pseudo code :
DateTime star t = now ; //start pour le test 1
for(int i=1 ; i < nbrOps ; ++i)
{
requete.ajout(insertion unitaire);
}
DateTime start2 = now ; //start pour le test 2
requete.Execute() ;
DateTime end = now ; //Ecart = end – start
Figure 7 : test d'insertions (temps de réponse (ms) en ordonnées, nbr d'insertions en abscisse)

4.2.5.2 Test en situation concurrentielle
Le test suivant porte sur un contexte où les connexions sont nombreuses et indépendantes. Pour
simuler cette situation, nous allons simplement imposer au programme de ne considérer que des
insertions simples directement transmises à la base de données. Comme précédemment, un grand
nombre d’insertions seront effectuées mais cette fois elles seront transmises directement à la base
de données sans regroupement. Bien qu’il ne s’agisse pas d’un scénario vraiment réaliste, cela suffira
pour se faire une idée des performances relatives de Linq et d’une connexion plus traditionnelle.
Le graphique qui suit ce paragraphe montre les temps nécessaires (exprimés en millisecondes) à
l’envoi de toutes les requêtes une à une pour les deux méthodes, le nombre de requêtes de chaque
lot étant repris en ordonnée. On voit clairement que la courbe intitulée « Linq sequence» croît
exponentiellement avec l’augmentation du nombre de requêtes à satisfaire. L’explication principale
en est que Linq doit manipuler des objets en mémoire comme nous l’avons vu dans la section
« Opérations fondamentales » de ce chapitre, dernier paragraphe. Chaque ajout créé un objet
supplémentaire et cette modification a lieu en mémoire centrale, ce qui sera fait beaucoup plus
rapidement que l’envoi de la requête à la base de données. Chaque soumission entraîne l’analyse du
marquage de chaque objet, ce qui ralentit l’ensemble du programme. La méthode ADO.NET,
représentée par la courbe « ADO sequence », ne manipule pas d’autres objets que les strings utilisés
pour construire les requêtes, celles-ci étant ensuite transmises au gestionnaire de la base de
données. Les temps d’accès varient donc selon une progression linéaire. La troisième courbe
présente sur le graphe représente les temps d’accès correspondant pour une utilisation idéalisée de
Linq. Utilisation idéalisée car l’envoi des requêtes n’est fait qu’au dernier moment, économisant ainsi
sur les temps d’analyse de marquages par la sentinelle. L’appel à la fonction SubmitChanges réalise
l’appel à la base de données et toutes les entités marquées comme étant « à insérer » vont générer
une requête Sql correspondant à leur insertion. En n’effectuant cette tâche qu’une seule fois, on
aperçoit que le gain de temps est conséquent 10 . Dans la réalité pratique, on pourrait regrouper
plusieurs requêtes par petits lots afin d’économiser un peu sur les accès successifs à la base de
données. Mais un appel unique est impensable, du fait que « la fin » est impossible à prévoir en
pratique ainsi qu’à cause des problèmes d’accès concurrentiels aux données. Les possibilités
d’optimiser Linq relèvent principalement de la gestion des conflits, de la synchronisation et du design
de l’application. Les performances en situation réelles sont certainement moins bonnes que le cas
idéal mais vraisemblablement plus proches de cette valeur que de celle de la version naïve.
10 Cette observation semble n’apparaître nulle part, *4+ le laisse tout juste sous-entendre.

Figure 8 : tests en situation concurrentielle (temps de réponse (ms) en ordonnées, nbr d'insertions en abscisse)
4.2.6 Conclusion
Linq to Sql effectue la correspondance entre objets et tables relationnelles avec des fichiers
spécifiques. Nous avons vu comment ces fichiers peuvent être automatiquement générés, délivrant
le développeur de la tâche ardue qu’est la réalisation d’un mapping objet relationnel. Les
mécanismes de gestion et de modifications des entités sont intuitifs et rapidement mis en œuvre,
comme nous l’avons fait avec un exemple concret. Plusieurs pièges restent tendus, guettant le
développeur inattentif mais ceux-ci sont nettement moins nombreux que dans un contexte d’accès
aux données en Sql. La plupart du code est vérifié à la compilation et un système de gestion de
conflits diminuera encore davantage les risques liés aux accès concurrentiels. En ce qui concerne la
performance, Linq s’est montré plus lent qu’une approche ADO.NET mais tout en restant dans des
limites acceptables. Le seul dommage semble être que Linq to Sql n’est en réalité que Linq to Sql
Server, ce qui limite fortement son champ d’application 11 .
11 Cette information est relativement dissimulée. C’est par le réseau développez.com que j’en ai eu
connaissance *13+, ce n’est apparu dans *1+ qu’au 12 e chapitre !

4.3 Linq to DataSet
Un DataSet est quelque chose de très proche de la notion des classes entités vues précédemment. Il
s’agit d’une représentation en mémoire d’une collection de données. Précisons qu’un DataSet est
une représentation générique puisque la collection de données est une représentation d’une source
de données que cette dernière soit d’origine relationnelle ou non. Les DataSets font partie de la
couche de données ADO.NET et n’ont donc pas été introduits par Linq. La couche d’accès aux
données ADO.NET fait un grand usage des DataSets, notamment en lecture pour conserver des
informations de structure liées aux données. Il est assez logique que Linq propose une
implémentation destinée à interroger ces structures. Nous allons poursuivre notre étude avec
l’analyse cette implémentation nommée Linq to DataSet. Cette section est grandement inspirée de
[1] et de [4]. Comme son nom l’indique, cette implémentation a pour cibles des objets de type
DataSet. Cette section ne sera pas découpée en sous-parties car Linq n’introduit que peu de
nouveautés en ce qui concerne les DataSets. L’étude approfondie des mécanismes sous-jacents aux
DataSets en général n’entre pas dans le cadre de ce travail et nous les passerons sous silence. Pour
pouvoir être utilisable par une implémentation Linq, il est nécessaire d’implémenter l’interface
IEnumerable. Sans nous étendre sur le sujet, signalons qu’il y a moyen de créer des DataSets
typés mais en toute généralité un DataSet doit être considéré comme non typé et n’implémente
donc pas la fameuse interface. Nous ne considèrerons ici que les DataSets non typés et nous
tenterons d’éclaircir comment les utiliser en tant que IEnumerable.
Etant un concept abstrait, les DataSets peuvent être construits depuis n’importe quel type de base
de données. Ils disposent en outre de mécanismes pour recréer la structure des tables relationnelles
sous-jacentes. Un mapping ? En effet, cela y ressemble fortement, mais celui-ci doit être
explicitement spécifié « à la main » par le développeur. Pour interroger de telles structures, Linq a
réalisé une implémentation spécifique appelée « Linq to DataSet ». Ceci permet de bénéficier de
toutes les améliorations apportées par Linq sur des structures pouvant s’interfacer sur n’importe
quel type de base de données. Ceci n’est en aucun cas le remède universel au vide laissé par Linq to
Sql puisque ce ne sont que les DataSets qui sont interrogeables. Leur construction ainsi que le suivi
des modifications vers la base de données sont encore à faire. Un DataSet représentant une cache de
base de données est classiquement construit à partir d’un DataAdapter (c’est-à-dire en utilisant la
couche ADO.NET). A noter qu’il est possible d’utiliser Linq pour remplir un DataSet sans passer par un
DataAdapter, mais cela suppose d’avoir préalablement récupéré les données et de les avoir sous
forme IEnumerable.
Pour pouvoir utiliser Linq sur une table d’un DataSet, il faut donc explicitement créer un mapping
avec la fonction TableMappings.Add(string sourceTable, string DataSetTable) du DataSet. Pour que
cette table soit énumérable, il faut utiliser l’opérateur AsEnumerable qui sera, dans ce cas-ci, utilisé
sur une DataTable. Voyons un exemple utilisant une base de données MySql (sa procédure de
construction est détaillée dans l’annexe 3 : utilisation d’une base de données MySql avec Linq to
DataSet).

using MySql.Data;
using MySql.Data.MySqlClient;
class Program
{
static void Main(string[] args)
{
MySqlConnection con = new MySqlConnection
("Database=MyLinqSql;Uid='root'");
con.Open();
}
DataSet ds = new DataSet("MySqlDataSet");
string selectString = @"SELECT * FROM objects1";
MySqlDataAdapter da = new
MySqlDataAdapter(selectString,con);
da.TableMappings.Add("objects1", "Table");
da.Fill(ds);
}
//interrogation du DataSet ds avec Linq to DataSet
DataTable dt1 = ds.Tables["Table"];
var dataSetQuery = from o in dt1.AsEnumerable()
select new {ID = o.Field("Id"), TEXT =
o.Field("Desc")};
foreach(var res in dataSetQuery)
{
Console.WriteLine(res);
}
//Fermeture de la connexion
con.Close();
Console.WriteLine("Appuyez sur Enter pour terminer...");
Console.ReadLine();
Le résultat de ce code, pour la base de données considérée est le suivant :
Figure 9 : Linq to DataSet pour interroger un DataSet construit avec MySql
Revenons maintenant sur les particularités de ce code. Nous avons bien créé une connexion MySql
que nous ouvrons et nous instancions un nouveau DataSet nommé MySqlDataSet. Nous créé un
nouveau DataAdapter avec l’instruction de sélectionner toutes les lignes de la table objects1. Un
mapping est ensuite créé pour pouvoir retrouver dans le DataSet la table équivalente à objects1 sous
le nom de Table. Le DataSet est rempli et nous définissons une nouvelle DataTable avec Table. Vient
ensuite notre requête qui a toutes les apparences d’une requête Linq qui devrait maintenant nous
être familière. Néanmoins, la référence à la table utilise l’opérateur AsEnumerable car une DataTable
n’implémente pas IEnumerable, comme nous l’avions dit plus haut. Mais nous voyons également

que les attributs de cette table doivent être accédés par la méthode Field en précisant
explicitement la nature de T, car le compilateur ne pourrait réaliser l’inférence depuis un champ
d’une DataTable. Ceci n’est simplement pas prévu. Peut-être cela changera-t-il dans le futur, mais
pour l’heure nous devons nous-mêmes fournir les informations qui sont en réalité des informations
de mapping encore une fois. Pour en revenir à l’opérateur AsEnumerable, il s’agit d’un opérateur
réalisant la conversion à la volée. Il s’applique à une séquence d’éléments et va les encapsuler dans
une nouvelle séquence d’objets implémentant IEnumerable. Cet opérateur peut être redéfini,
offrant ainsi la possibilité de créer des variantes adaptées au contexte.
En ce qui concerne les performances, la question est de mettre en balance ce que Linq apporte et les
délais introduits. Le mapping est réalisé par le DataSet lui-même et des instructions explicites au
niveau du code. Aucune logique de mapping automatique ne vient alourdir l’usage classique d’un
DataSet. Les performances en termes de temps de réponses seront fonction du contexte et non du
choix d’avoir ou non utilisé Linq. Notons tout de même que l’utilisation de telles structures n’est pas
toujours aisée et en particulier traduire une requête en langage naturel devrait être beaucoup plus
simple en utilisant Linq.
Avec Linq to DataSet, nous avons une solution portable vers tout type de base de données et même
vers d’autres systèmes de persistance car, rappelons-le, un DataSet représente simplement une
collection de données. Cela permet d’utiliser le confort lié aux requêtes de Linq, certes, mais Linq to
DataSet demande pas mal de réglages de la part du développeur, notamment d’assurer le suivi entre
le DataSet et la base de données. Il s’agit là d’un inconvénient majeur puisque cela peut amener des
problèmes liés à la synchronisation ainsi que toute la panoplie d’erreurs classiques liées à l’accès aux
données en Sql. Ceci ne constitue pas alternative à Linq to Sql mais plutôt comme un complément
pour répondre aux besoins des développeurs ayant choisi de manipuler des DataSets ou ayant à
maintenir des applications qui en font toujours usage. [4] maintient que « les DataSets sont une
composante importante de la couche ADO.NET », ce qui fait de Linq to DataSet un outil appréciable.
4.4 Linq to Entities
Une autre implémentation ayant pour cible des données relationnelles s’appelle Linq to Entities. Le
terme Entities dans son nom fait référence à la technologie Entity Framework, qui est une évolution
de la couche ADO.NET que nous appellerons par raccourci EF. EF est légèrement plus récent encore
que Linq. Nous allons brièvement introduire les idées fondatrices de cette technologie ainsi que ses
principaux concepts. Nous tenterons ensuite de mettre en lumière les forces et faiblesses de ce
framework, tout en particularisant cela aux contributions de Linq to Entities. Cette section puise ses
informations principalement de [5] pour EF et de [1] pour Linq to Entities.
4.4.1 Concepts fondateurs
L’idée au départ de l’EF est celle-là même qui a amené Linq. Nous pourrions résumer cette idée de
base en « une application orientée objet ne devrait pas dépendre des mécanismes de persistance ».
Nous n’allons pas expliquer à nouveau le problème de correspondance entre l’orienté objet et le
relationnel mais nous allons plutôt ce problème dans le contexte de la deuxième édition du
framework .NET. A cette époque pas si lointaine d’ailleurs, les accès relationnels se faisaient en
utilisant les services de la couche ADO.NET, elle-même une évolution des premiers services ADO
(ADO signifie ActiveX Data Object). Cette nouvelle couche apportait son lot de nouveautés, parmi
lesquelles l’interface IDbConnection, qui permettait de considérer une connexion générique à une

ase de données. Chaque fournisseur de données (il faut comprendre par là tant MySql que Oracle
ou Sql Server) implémentait cette interface au sein d’une classe concrète nommée client
(MySqlClient, OracleClient …). De même, la lecture des données se faisait en remplissant un DataSet
pouvant lui-même garder une structure très proche des tables relationnelles de la source. Pour en
revenir à l’idée énoncée plus haut, une application de l’époque dépendait de la nature de la source
de données en ce qui concernait la construction du DataSet et l’instanciation de la connexion. La
dépendance envers la source en elle-même et non son type est localisée au niveau des requêtes Sql
qui imposent de nommer les tables et attributs relationnels. Un changement dans la structure des
tables ou dans le type de la base de données imposent de réécrire tout le code responsable de la
connexion à la base de données et de la construction du DataSet. Selon les cas, il pouvait être
nécessaire de réécrire également certaines requêtes, en particulier lorsque les dialectes Sql parlés
par l’ancienne et la nouvelle source ne coïncidaient pas. Reprenons l’idée de départ mais
transformons-la en une nouvelle formulation dont le sens global sera identique à celui de la
première : « Une application orientée objet devrait pouvoir utiliser la logique conceptuelle des
données en faisant abstraction de son mode de stockage ». Avec la version 2 du framework, il n’est
pas possible d’utiliser la logique telle qu’elle serait définie dans un modèle conceptuel entitésrelations,
nous sommes condamnés à utiliser les tables telles que définies dans la base de données.
De même, il n’est pas possible de vérifier entièrement la logique dès que celle-ci interagit un temps
soit peu avec du code Sql. L’Entity Framework a été créé pour résoudre ces problèmes et se présente
comme une couche ajoutée par-dessus les mécanismes ADO.NET classiques. Manipuler des entités
conceptuelles sans directement agir sur la base de données, nous pouvons en effet comprendre que
ce concept est similaire à celui de Linq. Là où Linq propose une syntaxe unifiée pour les requêtes, EF
propose un accès conceptuel aux données défini indépendamment de la base de données.
4.4.2 Fonctionnement
Commençons par préciser quelques termes de vocabulaires et mettons-les en rapport avec la réalité
concrète du moins aussi concrète que peut être la réalité des accès aux données. Sans entrer dans
toutes les spécificités techniques, nous tenterons de mettre en lumière qui sont les principaux
acteurs de cet Entity Framework et quel est leur rôle.
Service objet est le terme officiel utiliser par Microsoft [5][1] pour décrire l’action d’EF. Les données
relationnelles n’ont pas changé, elles sont rendues disponibles en tant qu’objets. C’est ainsi que peut
être perçu le concept de service objet. Il est important de comprendre qu’il s’agit bien d’un service et
donc d’une couche supplémentaire posée sur la pile des mécanismes ADO.NET.
Une entité au sens d’EF est un concept décrit dans une modélisation entités-relations. Microsoft les
décrit parfois sous le nom de data object, littéralement objet donnée. Il s’agit donc de classes qui
vont jouer un rôle similaire à celui des entités au sens de Linq. Les entités d’EF regroupent des
données pouvant se retrouver sur plusieurs tables relationnelles et en termes relationnels, ce qui
approchent le plus de ces entités, ce sont les vues. Il est important de noter que les entités sont
mappées aux données relationnelles mais cette correspondance n’associe aucune ressource
directement aux entités. Cela pourrait se résumer de cette manière : les entités sont les objets
métiers qui décrivent la logique de l’application et lorsqu’on en vient à parler de la persistance, le
mapping permet aux entités de savoir où aller regarder.

Une relation est un lien entre deux entités ou plus. Il s’agit là des mêmes concepts que ceux présents
dans le fameux schéma entités-relations. Une relation peut être de diverses multiplicités : un à un, un
à plusieurs ou plusieurs à plusieurs. Une relation peut elle-même posséder des attributs et est donc
représentée par une classe.
Un objet contexte, ou context object en Anglais, est le terme pour désigner la classe en charge de la
gestion du modèle. La classe ou plutôt un de ses objets. Ce rôle s’apparente fort à celui du
DataContext de Linq to Sql et cet objet contexte gère à la fois le mapping et les instanciations
d’entités et de relations. Un seul objet contexte peut exister pour un modèle donné. Il intercepte
toutes les demandes, qu’elles soient faites aux entités, aux relations ou au modèle lui-même. L’objet
contexte est le point d’entrée de la couche des services objets (c’est ainsi qu’il est présenté dans la
documentation officielle fournie par Microsoft [5]).
Le modèle de données, appelé Entity Data Model ou EDM par Microsoft, regroupe les entités et leurs
relations. C’est en quelque sorte un schéma entités-relations mais les données peuvent y être
spécifiées déjà finement, notamment au niveau des types. Ce modèle peut être créé depuis une base
de données disposant d’un schéma entités-relations. Il peut également être créé à la main ou depuis
la structure de tables relationnelles d’une base de données. Dans tous les cas, des modifications sont
toujours possibles à postériori.
Le fonctionnement général d’EF est le suivant : l’application utilise des concepts dont la forme
correspond à la logique de l’application. Cet assemblage d’objets est manipulé directement en
mémoire et aucune interférence due à la couche relationnelle n’a lieu à ce niveau. Il n’y a que les
entités et relations ayant un rôle à jouer qui sont instanciées, les autres disparaissent dès leur rôle
terminé. L’objet contexte ne maintient que le minimum d’objets nécessaires. Lorsque ceux-ci
nécessitent un rafraîchissement ou lorsqu’ils font l’objet d’une demande d’écriture, l’objet contexte
va utiliser les informations de mapping à sa disposition pour créer les commandes Sql appropriées.
Sql étant devenu standard (ou presque), la seule question délicate est de gérer l’accès direct aux
données. Là et seulement là, le mapping contient des informations qui seront dépendantes de la
nature de la base de données. Ces informations sont utilisées pour créer des connexions et des
commandes avec la couche ADO.NET classique, c’est-à-dire telle qu’elle permet déjà de le faire
depuis la version 2 du framework .NET. Un changement du mode de stockage des données impose
de seulement changer quelques lignes au niveau du mapping. Les informations de structure pouvant
être utilisée pour recréer des tables relationnelles en correspondance avec le mapping actuel. Voici
le principe de l’Entity Framework.
4.4.3 Mapping
Le mapping est réalisé de manière distribuée, dans le sens où plusieurs fichiers y participent, chacun
apportant des informations différentes. Sans entrer dans les détails de leur syntaxe, un premier
fichier représente la structure des entités et relations, un deuxième fichier représente la structure
des données au niveau de la source relationnelle et le troisième fichier fait la correspondance entre
les deux [5]. Ceci se fait (presque) indépendamment de la nature de la base de données et la
structure de cette dernière peut être récupérée ou recréée à l’envie. A l’envie signifie dans la limite
où ce type de base de données est supporté par EF sans quoi ces étapes doivent être faites à la main.
Ceci est d’autant plus intéressant que le développeur n’a pratiquement aucune ligne de code à écrire
pour réaliser ce fameux mapping, un éditeur de modèle EDM graphique est fourni avec EF.

4.4.4 Rôle de Linq
En plus de tous ces mécanismes, Linq propose une implémentation ayant pour cible l’EF, nommée
Linq to Entities. L’EF disposant de son propre moteur de requêtes, Linq se présente comme une
syntaxe unifiée, qui resterait valable que l’on ait recours à l’EF ou non. Tant les requêtes Linq que
celles de l’EF utilisent les services objets, aucune des deux alternatives n’est réellement plus rapide
que l’autre 12 [1][5]. Précisons toutefois que les requêtes EF sont écrites dans un langage proche du
Sql nommé Entity Sql, ce qui laisse apparaître du code non vérifiable à la compilation, ce que Linq
permet justement d’éviter. De plus, nous pouvons faire la même remarque que celle faite lorsque
nous parlions de l’implémentation objet : Linq propose un formalisme de requêtes nettement plus
lisible et plus compact.
La difficulté de la mise en œuvre d’une application Linq to Entities tient davantage à la construction
du modèle de données qu’à la mise en place des requêtes. C’est pourquoi nous ne ferons pas
mention d’exemple dans cette section, la syntaxe Linq restant inchangée. Signalons tout de même
que certains opérateurs sont à manier avec prudence, en particulier les opérateurs d’agrégation
personnalisés qui peuvent ne pas être supportés, en toute généralité, par le gestionnaire de bases de
données.
4.5 Db Linq
Il s’agit ici d’une implémentation particulière, dans le sens où elle n’émane pas directement de
Microsoft mais d’une équipe mixte, regroupant des développeurs de Microsoft et d’autres
contributeurs indépendants. Son nom est d’ailleurs toujours un nom de code et non une désignation
standard « Linq to something ». Cette implémentation, résumée en une phrase, a pour but de faire
comme Linq to Sql mais mieux que Linq to Sql. La plupart des informations la concernant sont
disponibles sur [4] mais tout est rassemblé sur le site du projet en lui-même [14]. En effet, cette
implémentation se base sur l’API de Linq to Sql mais intègre d’autres types de bases de données que
Sql Server. Citons parmi eux MySql, Oracle et PostGreSql qui sont probablement les plus célèbres.
Pas grand-chose à ajouter sur cette implémentation, si ce n’est qu’elle est toujours en
développement. La dernière release est la version 0.20 datée du 16 avril 2010, ce qui en fait la plus
récente à l’heure d’écrire ce paragraphe.
Microsoft ne semble pas vouloir intégrer cette implémentation dans les librairies standards, pour une
raison indéterminée. Même si tous les outils de génération de code disponibles pour Linq to Sql n’ont
pas d’équivalents pour Db Linq, se contraindre à Sql Server semble peu judicieux. Nous reparlerons
plus loin du projet Mono qui a choisi quant à lui la solution Db Linq [14][15].
12 Il est d’ailleurs possible d’écrire des requêtes Entity Sql avec Linq en utilisant les objets ObjectQuery.

Chapitre 5 : Implémentation Xml
Le recours à des bases de données Xml s’est fortement répandu ces dernières années et tout
naturellement Linq propose une implémentation pour interagir avec ces structures. Xml est
cependant une technologie difficile à interfacer avec les langages orientés objet, en particulier
lorsque ceux-ci désirent créer du contenu Xml. L’approche classique utilise DOM 13 qui oblige à créer
l’ensemble des éléments avant de les rassembler. Linq to Xml propose une nouvelle syntaxe pour
créer du contenu Xml, la construction fonctionnelle. Elle permet de créer les éléments selon une
structure hiérarchique beaucoup plus compacte. Cette syntaxe est encore plus évidente dès lors que
nous utilisons Visual Basic 2008, car ce dernier a introduit dans sa dernière version les littéraux Xml.
Avec cela nous pouvons écrire directement le code en Xml, comme dans l’exemple cidessous
(inspiré de [1]) où nous créons un étudiant :
Dim exempleXml As XDocument = _
Schoonenbergh
Ecole polytechnique
MA2
Kleine Daalstraat
79
1930
Zaventem
Linq to Xml a été pensé pour manipuler du Xml tel que défini par le W3C 14 , c'est-à-dire pour
manipuler directement du contenu Xml sans passer par un intermédiaire. Cela permet d’interagir
avec de telles structures tout en restant dans un paradigme objet. La construction fonctionnelle est
supportée par l’assemblage System.Xml.Linq et peut être utilisée même sans recours direct à Linq.
Plusieurs classes sont définies pour représenter les éléments structurels du langage Xml, citons parmi
elles quelques exemples intéressants. La classe XObject tout d’abord qui est la classe de base pour
représenter n’importe quel objet Xml. Cette classe propose des méthodes qui représentent toute la
gestion structurelle de l’arbre Xml qui sera créé en mémoire. Des méthodes telles que AddBeforeSelf
ou AddAfterSelf permettent ainsi d’ajouter un élément à un endroit précis de l’arbre. Cette classe
supporte également l’annotation Xml. La classe XStreamingElement contient un arbre d’objets
IEnumerable et peuvent donc faire l’objet de requête. Les objets de cette classe réalisent
l’exécution différée des requêtes chargeant partiellement le résultat, ce qui permet de mieux doser
la quantité d’objets chargés en mémoire, bien utile dans une optique de performance. Parlons enfin
de la classe XDocument représentant un document Xml. Les objets de cette classe n’ont pas besoin
de références à un fichier pour être instanciés. Ils sont créés selon le pattern Factory et peuvent être
associés dans le futur à une référence (ou une URI) qui les reliera directement à du contenu existant,
le cas échéant.
13
DOM signifie Document Object Model. Il s’agit d’un ensemble de règles définissant les premières structures
Xml.
14
World Wide Web Consortium ; organisme de standardisation des technologies web.

Une particularité de l’implémentation Xml est que les résultats restent valables même si la source de
données est déconnectée. Ce qui veut dire que les entités présentes dans un résultat ne seront
resynchronisées que si la demande explicite leur parvient. Il est également possible d’imaginer
l’exécution d’une requête sur un document Xml particulier, récupérer ensuite le résultat et ré
exécuter la même requête sur un fichier différent (celui-ci devra vraisemblablement avoir une
structure très similaire au premier). Une autre possibilité d’utilisation de cette propriété est qu’il est
très facile d’utiliser un résultat issu d’une source de données relationnelle pour effectuer une
requête sur une structure Xml. Les entités Linq to Sql par exemple se resynchronisent
périodiquement mais ce n’est pas le cas du Xml. Les deux implémentations étant indépendantes, il
ne pose aucun problème d’utiliser l’une de ces sources de données pour supporter une requête sur
l’autre. Par exemple, nous pourrions extraire d’un fichier Xml tous les étudiants inscrits dans chaque
faculté et ensuite pour chacun de ces étudiants, faire une requête en base de données relationnelle
pour obtenir ses informations personnelles.

Chapitre 6 : En pratique
6.1 Ressenti général
Après ce vaste tour d’horizon de Linq, il est temps de prendre un peu de recul et de faire le point sur
ce que nous pouvons en retirer. Qu’a apporté cette étude ? Voila une question qu’il est bon de se
poser. La découverte de Linq s’est faite depuis les bases, tout comme ce fut relaté dans ce rapport.
Nous avons introduit un ensemble de mécanismes fondateurs avant de décortiquer les différentes
implémentations proposées par Linq. L’exploration de ces diverses implémentations et la mise en
œuvre de cas concrets se sont avérés parfois surprenants, révélant des comportements inattendus
(cf tests de performance pour Linq to Sql) ou au contraire des avantages conséquents (comme pour
l’exemple de l’implémentation objet). La méthode appliquée tout au long de cette étude a été de
partir des bases théoriques en allant progressivement vers des considérations de plus en plus en
phase avec la réalité concrète. Bien qu’il soit tentant d’explorer encore et encore certaines options,
nous nous sommes efforcés de nous en tenir au sujet initial qui ne concerne que Linq. Des ouvertures
vers des technologies passionnantes comme l’Entity Framework ont été tentées mais les essais et
explications sont restés centrés sur Linq.
La plus grande difficulté rencontrée durant cette étude concerne la disponibilité de la
documentation. En effet, Linq était partie intégrante d’une solution propriétaire, une très large
majorité des informations techniques est concentrée sur le site officiel de Microsoft ou dans des
livres édités par Microsoft Press. Certains sujets sont encore mal documentés du fait de leur jeunesse
et de leurs rapides mutations. Un des problèmes rencontrés à ce sujet fut d’avoir accès à des
explications tronquées, certaines parties étant apparemment considérées comme triviales. Lorsque
ce n’est pas l’avis du lecteur, c’est rapidement problématique pour ce dernier. De même, certains
sujets très récents comme l’Entity Framework ne proposent que des informations fragmentaires et
parfois contradictoires, le plus souvent à cause de changements survenus durant la version beta non
répercutés dans la documentation. Heureusement la communauté qui soutient le développement
.NET est nombreuse et les accès en avant-première à certaines technologies encore en
développement permettent à certains spécialistes de rédiger des explications complémentaires
souvent utiles (il s’agit des sources *13+ et *6+ principalement). Ce passage est également l’occasion
de remercier tous ces contributeurs pour leur travail et leur dévouement. Proposant généralement
des informations dispersées sur des blogs ou des forums communautaires, ils sont parfois auteurs
d’une simple phrase permettant le déclic. Leurs interventions sont aussi l’occasion d’offrir un point
de vue différent de l’omniprésent Microsoft. Dans la documentation officielle, tout semble toujours
simple et harmonieux. Plusieurs retours d’expérience ont également permis d’adopter une vision
plus objective sur l’ensemble des sujets abordés.
6.2 Points forts, points faibles
La première remarque qui s’impose après ce que nous avons vu, c’est de se dire que Linq permet
d’écrire du code beaucoup plus simplement. Les requêtes y sont écrites dans un langage plus proche
du langage naturel et les erreurs sont détectées à la compilation. Durant les différents tests réalisés
préalablement à l’écriture de ce rapport, le temps nécessaire à l’écriture de requêtes Sql a été
constaté comme étant entre deux et trois fois supérieur au temps requis pour produire des requêtes
Linq équivalentes (est compris dans ces mesures le temps consacré à l’écriture des requêtes et à leur
débogage). En termes de productivité, Linq constitue déjà une avancée majeure. Au-delà de ce gain
de performances humaines, Linq améliore la maintenabilité d’un code car il est plus lisible d’une part

et plus abstrait vis-à-vis des données d’autre part. En termes de performances machines, seules
certaines implémentations en pâtissent, en particulier Linq to Sql. Les autres implémentations ne
rajoutent que peu de choses entre le code et la gestion du stockage des données, ceci n’influence
donc que légèrement sur les performances. Les possibilités d’optimisation sont également plus
visibles pour Linq qu’en ce qui concerne la couche ADO.NET où une connaissance des subtilités est
souvent nécessaire. Ceci n’est nullement le fruit d’une mesure cependant, simplement une
impression personnelle partagée par divers interlocuteurs rencontrés sur des sites internet
spécialisés. Bien qu’il ne s’agisse pas d’une réelle information, cette tendance semble montrer que
l’utilisation de Linq continuera de se répandre tant qu’il sera question de requêtes sur des données
relationnelles.
Les techniques d’accès aux données relationnelles datant de la deuxième version du framework .NET
sont sans comparaison avec le confort offert par Linq. Mais si nous nous plaçons dans une optique de
continuité, l’arrivée de Linq ne signifie nullement l’abandon de la couche ADO.NET. Certes manipuler
la couche d’accès aux données signifie utiliser un autre langage avec tous les désagréments que cela
comporte, mais Linq est une alternative nouvelle. La plupart des développeurs chargés d’écrire des
requêtes ont probablement toujours une bonne connaissance du Sql et des bases de données en
général. Linq est très plaisant du point de vue du débutant mais certaines personnes décrient son
utilisation abusive, arguant du fait que son utilisation à outrance finira par provoquer l’oubli des
mécanismes subtils pour accéder aux données [13]. Ne plus être conscient de la cuisine interne
réalisée par les outils de génération de code peut certes s’avérer dangereux, mais est-ce vraiment ce
à quoi nous risquons d’arriver ? Probablement pas, car les bases de données en elles-mêmes sont
toujours la solution numéro un dans le monde de la persistance et ces bases de données se doivent
d’être gérées et maintenues par des experts. Des spécialistes du relationnels pour qui les requêtes ne
sont qu’une toute petite partie de ce que peut réaliser une base de données. Créer des procédures
stockées, des déclencheurs (triggers) et ce genre de choses, cela aura toujours son lot d’artisans
œuvrant avec des lignes de commandes bien loin de Linq et de ses interfaces graphiques.
Linq se présente comme le compagnon idéal du développeur d’application qui souhaite ne pas être
entravé par la présence des mécanismes de persistance. La couche ADO.NET restera de toute façon
utilisée en arrière-plan pour réaliser les dialogues intimes avec les bases de données. Linq est donc
probablement plus un complément qu’un concurrent pour ADO.NET. Il est néanmoins dommage que
des implémentations comme Db Linq ne soient pas plus soutenues par Microsoft, mais cela sera
peut-être amené à changer.
Si nous sortons du seul point de vue relationnel, Linq permet avant tout de manipuler des données
sans se préoccuper de savoir d’où elles viennent. C’est à la fois une force et une faiblesse. La force
est d’augmenter l’abstraction du code vis-à-vis du stockage, ce qui est vital nous ne le répèterons
jamais assez. La faiblesse est qu’il devient beaucoup plus facile de commettre des erreurs par
ignorance. Ainsi une persistance assurée par plusieurs bases de données redondantes permettra des
réponses rapides, mais un même code pourra s’avérer problématique s’il prend pour cible un unique
fichier Xml de très grande taille. Il faut rester conscient qu’utiliser Linq ne sera pas systématiquement
une bonne chose et devra toujours être attentivement examiné. Linq dans son ensemble commence
à atteindre la maturité nécessaire pour s’attirer la confiance des développeurs, son utilisation va sans
doute devenir généralisée dans le monde .NET.

6.3 Quelles alternatives
Comme nous l’avions précédemment fait remarquer, le problème de la dépendance par rapport au
stockage des données n’est pas nouveau. Linq y apporte sa contribution et nous avons résumé les
principales techniques qui étaient utilisées à l’époque de la deuxième version de .NET. Mais qu’en
est-il des autres langages ? .NET n’a pas le monopole de l’orienté objet et Linq est résolument lié au
framework. Il est impensable qu’un langage orienté objet tel que Java n’ait pas développé de
solutions de son crû pour tenter de créer davantage d’abstraction vis-à-vis de la couche de
persistance des données. Nous allons maintenant nous pencher sur différentes technologies et leurs
points communs avec Linq.
6.3.1 Java
Java reste une pointure dans le domaine des langages de programmation orientés objet. En
perpétuelle concurrence avec son grand rival .NET, leurs évolutions respectives se sont toujours plus
ou moins suivies de près. Ainsi, les accès aux données relationnelles se faisaient via un pilote Odbc 15
en C# 2.0 et Java 5 faisait de même avec Jdbc, pour sa part. Voyons maintenant quelles sont les
solutions actuellement proposées pour réaliser une persistance abstraite en Java.
6.3.1.1 JDO
Les paragraphes consacrés à l’étude de JDO sont presqu’entièrement inspirés de *8+ et de la
documentation qui s’y trouve. JDO est l’acronyme désignant Java Data Object. Il s’agit d’une librairie,
plus exactement d’une API, standard pour réaliser la persistance des objets. La première version de
JDO est apparue en 2002 et la seconde version est disponible depuis 2006. Comme presque tout ce
qui concerne Java, cette librairie est open source. La version 2.1 appelée aussi Apache JDO est
toujours en cours de développement à l’heure où ces lignes sont écrites. Cette librairie est décrite
comme supportant tout type de stockage et représentant les données stockées à l’aide de POJO
(Plain Old Java Object), ce qui pourrait se traduire par de bons vieux objets Java. JDO se décline en
plusieurs interfaces, comme le fait Linq, et ces implémentations permettent d’utiliser différents
stockages de données parmi lesquels des bases de données relationnelles, objet ou Xml, un système
de fichiers ou même certains stockages plus exotiques comme les bases de données Big Table de
Google 16 .
JDO présente la persistance du point de vue du développeur objet, de manière transparente. Pour
décrire brièvement les classes qui entrent en jeu, nous avons un gestionnaire de persistance, des
requêtes et des transactions. Le gestionnaire est responsable de la maintenance des instances de
persistance qui ne sont en fait que l’équivalent des entités en mémoire au sens de Linq. Le
gestionnaire est également chargé d’exécuter les requêtes et transactions qui lui sont passées. Le
principe est, sur le fond, très similaire à Linq to Sql : nous avons un gestionnaire de contexte qui gère
des entités persistantes. Pour interroger les sources de données, JDO a recours à un langage qui lui
est propre, le langage JDOQL. Cet acronyme est l’abréviation de Java Data Object (JDO) Query
Language et n’est pas directement lié à OQL comme nous pourrions l’imaginer. Il est intéressant de
noter que ce langage propose deux syntaxes alternatives, la syntaxe dite déclarative et celle dite du
Single String. Pour ne pas trop nous perdre dans l’analyse de toutes les possibilités syntaxiques, nous
allons simplement examiner cela avec un exemple tiré du site officiel du projet Apache JDO [8], situé
page suivante.
15 Il existe d’autres pilotes plus anciens, odbc était le dernier en date lors de la release de C# 2.
16 Ceci est mentionné à l’adresse suivante : http://db.apache.org/jdo/impls.html

Declarative JDOQL :
Query query = pm.newQuery(mydomain.Product.class,"price < limit");
query.declareParameters("double limit");
query.setOrdering("price ascending");
List results = (List)query.execute(150.00);
Single-String JDOQL :
Query query = pm.newQuery("SELECT FROM mydomain.Product WHERE " +
"price < limit PARAMETERS double limit ORDER BY price
ASCENDING");
List results = (List)query.execute(150.00);
Pour bien comprendre l’exemple ci-dessus, précisons que l’objet nommé pm désigne le gestionnaire
de persistance qui est le point de passage obligé pour toute requête ou transaction effectuée sur ses
données. Cette manière de procéder est différente de celle de Linq. JDO considère une requête
comme un objet qui sera traité de manière centralisé alors que nous avons vu que Linq adresse ses
requêtes directement sur les collections de données. Le recours au gestionnaire n’avait lieu que
lorsqu’une opération générale était nécessaire, comme dans le cas du SubmitChanges que nous
avions abordé dans la partie sur les implémentations relationnelles.
En ce qui concerne le mapping, il est réalisé à la fois par des dénominations explicites dans le code et
par un fichier Xml. Au niveau du code, les informations ajoutées servent à avertir les objets s’ils
doivent ou non s’occuper de leur persistance ou de celle de leurs attributs. En ce qui concerne le
fichier Xml, les informations spécifient quelle classe est la représentation de quelles données et où
trouver ces dernières. Diverses autres informations participent au mapping mais nous ne les
détaillerons pas ici. L’important est de constater que le mapping se fait au niveau du code avec des
indications qui permettent de savoir comment gérer les objets persistants et aussi avec un fichier de
correspondance qui indique quel attribut correspond à quelle donnée enregistrée. La seule
différence notable entre Linq et JDO en ce qui concerne le mapping, c’est que Linq tente d’encore
faciliter la tâche du développeur avec l’intégration d’éditeurs graphiques.
6.3.1.2 Hibernate
Une grande partie des informations relatives à Hibernate provient de [16]. Hibernate a été conçu à
l’origine pour simplifier la persistance d’objets dans des bases de données relationnelles. Ses
fonctionnalités se sont quelque peu élargies mais Hibernate reste un outil cantonné au domaine du
relationnel. Son rôle est d’offrir un mapping objet relationnel plus aisé que lorsqu’il est réalisé à la
main avec la technologie Jdbc. Hibernate gère les mécanismes de persistance, c’est-à-dire les
enregistrements et chargements depuis la base de données, mais il laisse le développeur écrire des
requêtes dans le langage de son choix parmi lesquels le langage propre à Hibernate (HQL), le langage
générique de l’interface de persistance implémentée par Hibernate 17 (JPQL) ou directement en Sql.
Là où Linq fait figure de canif suisse intégrant de multiples possibilités via un outil passe-partout,
Hibernate est la boîte à outils du développeur désireux d’avoir le choix des armes.
A noter que Hibernate est souvent considéré comme une solution à n’utiliser que lorsque la situation
est adaptée [13] 18 . Alors que Linq se veut être une solution flexible, avec abstraction du stockage,
17 Il s’agit en réalité d’une interface définie dans la librairie JPA, mais par abus de langage nous dirons que
l’interface implémentée est JPA. JPA signifie Java Persistence API.
18 Il s’agit là d’interventions non officielles mais néanmoins non(ou très peu) démenties par la communauté*13+

Hibernate est un choix lié au monde relationnel offrant un ensemble de fonctionnalités pas toujours
aisées à maîtriser. Précisons tout de même qu’Hibernate est bien plus ancien que Linq, puisque sa
création remonte à 2001. Bien que les interfaces JPA aient été créées pour englober plusieurs
utilitaires de persistance dont Hibernate, ce dernier reste davantage un ORM qu’une solution
intégrée au langage. De manière générale, le rôle des implémentations de JPA reste borné à
effectuer une persistance plus simple lorsque les données sont stockées sous forme relationnelle.
6.3.2 .NET
Bien que Linq y soit récent et que, au contraire de Java, ce langage ne s’enrichisse pas directement
sur la base d’une communauté de contributeurs, .NET et C# en particulier proposent d’autres
alternatives pour réaliser la persistance des données sans passer par toute la panoplie des
commandes ADO.NET. Les autres méthodes que nous allons aborder sont, de manière générale,
destinées à un autre public que celui prévu pour Linq.
6.3.2.1 NHibernate
Comme son nom l’indique, il s’agit là d’une version d’Hibernate adaptée au langage C# (le N est une
abréviation courante en préfixe d’une technologie pour signifier qu’elle s’applique à .NET). Les
informations relatives à NHibernate émanent de [17]. Le cœur d’Hibernate a été porté vers .NET et
son utilisation a été quelque peu adaptée pour mieux répondre aux attentes des développeurs .NET.
Cet outil a été développé par la même équipe que celle en charge de la version Java. De par sa
structure et son mode de fonctionnement, il s’agit encore une fois d’un ORM qui vient se greffer sur
une architecture déjà existante, celle de l’incontournable couche ADO.NET. NHibernate est présenté
comme une solution mature, capable de réaliser la correspondance objet relationnel de manière
transparente pour le développeur. NHibernate répond à une demande particulière : ne pas être
limité par l’ORM en étant sûr que, de toute façon, les données seront sauvées dans une base de
données relationnelle. Il s’agit là d’une optique quelque peu hors des objectifs de Linq qui souhaite
créer une abstraction avec le stockage tout en mettant davantage en avant la facilité de mise en
œuvre. A noter que depuis peu, NHibernate propose un module complémentaire Linq to NHibernate
permettant d’utiliser la syntaxe Linq pour réaliser des requêtes avec NHibernate [18].
6.3.2.2 Entity Framework
Voici une figure connue, les informations à son sujet sont toujours majoritairement issues de [5].
L’Entity Framework, que nous avions brièvement introduit dans la section Linq to Entities, est lui
aussi en soi une alternative à Linq. Il serait mieux de parler de complémentarité entre ces deux outils
que de concurrence, néanmoins il reste possible d’utiliser l’un sans l’autre. L’Entity Framework
permet essentiellement deux choses : choisir la forme des entités à manipuler et automatiser toute
la cuisine interne nécessaire pour pouvoir fournir des entités personnalisées de manière efficace.
Comme nous l’avions vu, cela ajoute également un niveau d’abstraction vis-à-vis de la base de
données, car le code manipulant les entités est bien séparé des manipulations relationnelles. Linq
apporte quant à lui la puissance et la simplicité d’utilisation de son langage de requêtes. L’Entity
Framework a donc pour vocation d’aider à définir la « business logic » de l’application sans entrave
de la part du stockage des données, alors que Linq permet de récupérer des éléments précis plus
aisément. Il est tout à fait envisageable de vouloir garder la main sur le langage de requêtes car, en
effet, celles-ci seront traduites tôt ou tard en Sql. Dans cette optique-là, l’utilisation de l’Entity
Framework se fera sans l’aide de Linq. En résumé, si la difficulté se situe au niveau de l’architecture
du code ou de la jonction entre la logique métier et la couche de persistance des données, Entity

Framework est une solution envisageable. Le champ d’application de Linq sera plutôt atteint si la
difficulté réside dans la capacité à produire ou à vérifier des requêtes vers des données persistantes.
Ces outils répondent à des besoins séparés et n’entrent pas en concurrence directe.
6.3.3 Autres langages
Nous avons vu un peu ce qui se faisait en Java comme en .NET pour mettre en place une aide à la
persistance. Ces deux langages sont probablement les porte-drapeaux du paradigme orienté objet et
pourtant ils n’en sont pas non plus les seuls représentants. Le PHP est très fort présent dans le
domaine du développement web et ce domaine fait généralement un usage extensif des moyens de
persistance. Nous allons maintenant parcourir des approches plus globales, permettant de nous faire
une meilleure idée des types de persistance recherchées et pourquoi. Les paragraphes suivants sont
issus de diverses sources, principalement [19],[20] et [21].
6.3.3.1 Persistance personnalisée
De nombreux ORM existent sur le marché et ce depuis maintenant quelques années. Les plus connus
restent ceux liés à Java et .NET. Pourquoi ? La première chose qui devrait nous mettre la puce à
l’oreille est que ces langages sont fortement typés, à l’inverse du PHP ou de Python. Il est impératif
de connaître le type d’une variable avant de pouvoir l’utiliser. Or les types sont quelque peu
différents lorsque nous passons du monde relationnel à celui des objets, ou vice versa. De même, les
grandes applications orientées objet s’appuient sur des architectures parfois titanesques et cela
entraîne invariablement une complexification structurelle des données à stocker. Les langages
comme PHP et Python ont quant à eux une réputation de légèreté et de facilité de mise en œuvre.
Vu de cet angle là, la multiplication des utilitaires de persistance pour Java et .NET s’explique mieux.
Leur supériorité numérique également. Nous avons vu le cas de Hibernate et de NHibernate dans les
paragraphes précédents, précisons tout de même qu’il en existe des dizaines d’autres. Il existe
malgré tout des ORM pour PHP (Doctrine en est le plus connu) et Python (avec l’ORM SQLAlchemy).
Ceux-ci sont souvent des versions d’ORM utilisés en Java portées vers le langage cible. Des langages
comme PHP et .NET sont difficilement comparables lorsque le domaine d’application est défini, il
n’est donc pas réellement question de concurrence entre Linq et ces différents outils.
Une autre situation qui se généralise de plus en plus est d’embarquer sa propre couche de
persistance, offrant l’abstraction désirée. C’est particulièrement vrai pour des outils de conception
« tout en un », tels des fournisseurs d’ERP (TinyErp s’appuie sur du code Python [24]) ou de
gestionnaire de contenu CMS lorsqu’ils sont développés en PHP ou Python. Les gestionnaires de
contenu intègrent souvent la possibilité d’insérer du code à plusieurs niveaux, que ce soit lors de la
création d’une page ou l’écriture d’un script dont l’appel est géré par le CMS. Bien qu’il s’agisse
essentiellement d’outils spécialisés dans le développement web, notons que ces solutions intègrent
chaque jour plus de fonctionnalités ce qui les approchent très fortement du statut d’environnement
de développement. Parmi ceux-ci, nous pouvons citer des exemples comme eZ Publish [22] ou
Drupal [23]. Ces outils de gestion de contenu permettent d’insérer du code pratiquement n’importe
où et constituent en eux-mêmes des outils de développements (tous deux s’appuient sur du PHP). Ils
ont chacun à leur manière établis une couche de persistance tentant de faire abstraction de la nature
de la source de données. Un ensemble de classes prennent en charge les différents types de bases de
données et les interactions avec le stockage sont créées à la volée, selon le type de stockage détecté.
L’abstraction vis-à-vis du support de persistance est une idée similaire à celle de Linq mais les
requêtes demeurent écrites en Sql ou en XQuery. Ceci n’est pas très surprenant car les langages non

typés comme PHP n’ont généralement pas recours à une phase de compilation. Dès lors, la
vérification syntaxique n’a plus de sens. Simplifier l’écriture des requêtes pourrait être fait mais
gardons en tête que la majorité des applications réalisées avec ces CMS et ERP sont depuis
longtemps liées à des bases de données. Pour ces développeurs, il est envisageable que l’écriture de
requêtes soit un chapitre depuis longtemps maîtrisé, ou du moins avec lequel ils ont établis leurs
habitudes.
6.3.3.2 Bases de données objets
Les bases de données objets sont restées, depuis leur apparition, en marge des autres systèmes de
persistance. Certains indices laissent croire qu’elles font l’objet d’un regain d’intérêt, spécialement
pour des applications légères. Leur gros problème a toujours été de pouvoir justifier le changement
de toute une couche de persistance pourtant déjà fonctionnelle [3]. Un tel changement implique une
migration des données en plus d’une réécriture conséquente des applications qui font usage de la
persistance.
Une base de données objet constitue un moyen de réaliser physiquement la persistance et non de
fournir une aide au programmeur en soi. Bien sûr la syntaxe du langage Oql, permettant d’interroger
ces bases de données, est très proche des langages orientés objet. Mais elle n’est pas réellement
intégrée au langage comme l’est Linq. Si nous en parlons ici c’est pour faire un plus ample lien entre
les deux. Plusieurs logiciels de gestion de bases de données orientées objet ont littéralement sauté
sur l’occasion pour se mettre dans la mouvance de Linq. Ainsi nous pouvons citer db4o qui utilise
Linq comme langage de requêtes 19 mais aussi Eloquera, une base de données destinée au
multimédia, ou encore Siaqodb 20 qui intègre même un éditeur de requêtes pour Linq. L’écriture de
requêtes avec Linq se fait déjà dans une optique orientée objet, que des bases de données objet
tentent de s’aligner dessus n’est finalement pas surprenant. Est-ce que Linq contribuera à donner un
second souffle aux bases de données orientées objet ? L’avenir nous le dira.
19 Information vue sur http://www.db4o.com/s/linqdb.aspx
20 Information vue sur http://siaqodb.com/

6.4 Evolutions de Linq
Nous allons maintenant parler d’avenir. De ce qui est en projets, en développement et de ce qui
pourrait le devenir. Microsoft a montré sa volonté d’avancer dans le domaine de la gestion des
données persistantes mais bien des choses restent à faire.
6.4.1 Version 4
La quatrième version du framework .NET est en phase de beta test au moment où sont rédigées ces
lignes. Lors d’une annonce faite le 28 octobre 2008 21 , l’équipe en charge du développement de Linq
précisait que Linq to Sql serait désormais considéré comme une moins prioritaire, tous les efforts
étant dirigés vers Linq to Entities. Ceci en raison de sa capacité à s’adapter à de plus nombreux types
de bases de données relationnelles. Linq to Sql n’a pas été abandonné pour autant, mais les
changements annoncés ressemblent plus à un planning de résolutions de bogues qu’à la mise en
place d’une évolution. Linq to Entities quant à lui semble avoir le vent en poupe, tout comme son
compagnon l’Entity Framework. Des améliorations concernant l’ergonomie d’utilisation et des
possibilités étendues comme la création d’une base de données depuis un modèle édité
graphiquement sont actuellement déployées dans la version en test du framework et de Visual
Studio 2010. Quelques changements précieux comme la capacité de « self tracking » des objets
entités vont encore alléger la charge du développeur. En ce qui concerne strictement Linq, les
améliorations concernent la flexibilité d’utilisation en offrant davantage de réglages optionnels. Leur
mise en pratique semble encore un peu floue et les informations obtenues sont parfois
contradictoires, il est donc dur d’être précis. Ce qui est sûr c’est que Linq to Entities continuera son
petit bonhomme de chemin.
En ce qui concerne les autres implémentations de Linq il n’y a pas grand-chose à signaler. Les
changements apportés par la version 4 22 semblent surtout tenir de la correction.
6.4.2 Ce qui reste à améliorer
Le passage par l’Entity Framework résout en partie le problème posé par Linq to Sql et sa non
portabilité vers d’autres bases de données que Sql Server. Tant qu’il y aura des options non
proposées par Linq, son utilisation restera l’objet d’un compromis. La synchronisation des entités
n’est par exemple pas toujours évidente et les mappings auto-générés offrent toujours le risque que
les mécanismes cachés soient mal compris. Ces fonctionnalités feront sans doute l’objet
d’améliorations progressives mais pour l’heure nous ne pouvons qu’espérer. Il est bon de noter que
Microsoft et l’équipe ADO.NET en particulier essaient de se montrer comme étant à l’écoute du
développeur, précisant régulièrement que les retours de la communauté seront pris en compte.
Malgré cela, plusieurs implémentations de Linq comme Linq to NHibernate citée précédemment ne
sont pas suivies par Microsoft. Bien que cela puisse paraître normal puisqu’ils n’en sont pas les
auteurs, cela laisse le risque qu’une modification des spécifications de Linq vienne mettre hors jeu
ces implémentations extérieures. Bien sûr ce risque existe pour de nombreuses technologies, mais
l’évolution de Linq semble encore hésitante, parlant tantôt d’ajouter telle fonctionnalité, tantôt de
laisser tomber telle autre, livrant les informations officielles au tout dernier moment. Ce qui nous
amène à parler d’une amélioration plus que souhaitable, celle concernant la documentation. En
dehors de certains ouvrages, l’ensemble de la documentation sur Linq se trouve en ligne, sur le site
21 http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-
roadmap.aspx
22 Consulter à ce sujet : http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40

de la bibliothèque MSDN. Les livres deviennent rapidement dépassés, constituant rapidement des
sources d’informations obsolètes et parfois dangereuses. La documentation en ligne est dispersée et
ne propose pas la même visibilité que celle de l’API de Java. Cela amène rapidement à devoir récolter
des informations morcelées et de tenter de les mettre soi-même en place. Le but de cette étude était
d’explorer et de tester, ce qui fait que les miettes d’informations ne constituaient pas réellement un
problème dans la mesure où des tests étaient faits de toute façon. Pour une application
professionnelle en revanche, jouer à la devinette est à déconseiller. Une meilleure présentation de la
documentation y constituerait une aide précieuse.
6.4.3 Linq et Mono
Avant de faire le point sur ce tour d’horizon de Linq, il nous reste un dernier point à traiter qui est
celui du projet Mono. Le projet Mono consiste à porter les spécifications du framework .NET vers les
plateformes Linux. La version actuelle de Mono est la 2.6, sortie le 14 décembre 2009. L’ensemble de
cette section tire ses informations de [15] et de [14] en ce qui concerne Db Linq. Elle intègre, parmi
d’autres nouveautés, les fonctionnalités Linq to Sql avec quelques variantes. Il s’agit en réalité de
l’implémentation Db Linq partageant une partie de l’API de Linq to Sql. La plus importante différence
est que la version Mono de Linq to Sql n’est pas limitée à Sql Server mais permet de gérer des
fournisseurs de données comme FireBird, MySql, PostGreSql, Ingres, Oracle et SqlLite [14]. [15]
précise que « La totalité du code n’est pas encore portée », il est par exemple signalé que le support
de l’assemblage System.Data.Linq n’est pas total. Cet assemblage contient la définition des entités et
l’ensemble des extensions de méthode. Il est amusant de constater que Linq avec Mono est plus
polyvalent que dans sa version Microsoft qui, pour une raison mystérieuse, ne semble pas vouloir
soutenir activement l’implémentation Db Linq. Notons que le projet Mono est développé en
partenariat avec les équipes Microsoft et qu’un tel échange devrait pourtant être possible. Affaire à
suivre.
Bien que n’offrant qu’une implémentation, Mono permet d’utiliser Linq avec des bases de données
relationnelles. Ceci donne une dimension supplémentaire à Linq, qui devient une solution beaucoup
plus portable. L’abstraction vis-à-vis du stockage des données est une chose, la réutilisabilité d’un
code en est une autre. Avec le support de Mono, Linq devient un choix viable dans un contexte multi
plateformes, ce qui permet de concurrencer les solutions « à la Java ».

Conclusion
Nous avons vu quels étaient les mécanismes permettant au langage d’implémenter les bases de Linq.
Ces mécanismes sont pour la plupart des évolutions de ce qui était proposé dans le deuxième
framework .NET. Partis de ces bases théoriques, nous avons découvert le formalisme de requêtes
proposé par Linq, formalisme proposant une syntaxe unifiée pour toutes les implémentations. Linq
se décline en une série d’implémentations, chacune destinée à des types de données particuliers.
L’implémentation objet a d’abord été abordée, en détaillant les opérateurs jugés comme étant les
plus intéressants. Un cas pratique a été envisagé, l’implémentation objet de Linq y a montré son
intérêt vis-à-vis de techniques plus classiques. Plusieurs implémentations relationnelles ont ensuite
été abordées, avec une attention toute particulière pour Linq to Sql, implémentation vedette de Linq.
Les concepts y ont été vus en détails avant d’analyser les performances de cette implémentation
confrontée à un accès classique aux données. D’autres implémentations ont ensuite été examinées,
mettant en avant l’autre technologie phare de Microsoft, l’Entity Framework. L’exploration de Linq
s’est poursuivie avec l’étude de l’implémentation Xml et des nouveautés qu’elles apportaient, en
particulier dans la gestion de données directement en Xml. Avec un peu de recul, le point a été fait
sur l’expérience Linq ainsi que sur ses forces et faiblesses. L’abstraction suppélmentaire du code visà-vis
de la couche de persistance est un apport très positif. Les anciennes techniques d’accès
relationnels ne sont pas obsolètes, le besoin de gérer plus finement des bases de données sera
toujours présent. Malgré tout, Linq constitue un danger pour le développeur non averti. Les tests ont
montré qu’une connaissance des mécanismes utilisés en interne s’avère indispensable pour éviter les
pièges qu’une trop grande facilité pourrait masquer. Le manque de documentation claire et
accessible est également à déplorer. L’étude s’est poursuivie par l’examen des alternatives
envisageables à Linq et leurs correspondances relatives. De nombreux concurrents existent mais très
peu proposent une abstraction aussi forte que celle de Linq. Seul JDO en Java semble constituer une
alternative sérieuse à Linq et .NET. Pour finir ce tour d’horizon, les possibles évolutions de Linq ont
été discutées. Il est difficile de prévoir ce que l’avenir nous réserve mais pour l’heure Linq semble se
stabiliser. Le projet Mono en est encore à ses débuts avec Linq mais la portabilité qu’il offre au projet
Linq tout entier laisse croire que son évolution à lui aussi se poursuivra. Linq, nouveau paradigme,
annonciateur de la programmation orientée données ? Un long chemin reste à accomplir, l’avenir
nous donnera la réponse.

Bibliographie
1. « Programming Microsoft Linq », Paolo Pialorsi et Marco Russo, éditions Microsoft Press,
2008.
2. « C# et .NET, version 2 », Gérard Lebrun, éditions Eyrolles, 2007.
3. « L’orienté objet, troisième édition », Hugues Bersini, éditions Eyrolles, 2007.
4. « Documentation en ligne du réseau de développeurs Microsoft »,
http://msdn.microsoft.com, technical references on C# 3.0 and 3.5
5. « Technical preview of Entity Framework », http://msdn.microsoft.com/enus/library/aa697427%28v=VS.80%29.aspx
6. « Tout sur WPF, Linq, C# et .NET en général », Thomas Lebrun,
http://blogs.developpeur.org/tom/default.aspx
7. « Programming Entity Framework », Julie Lerman, O’Reilly Media, janvier 2009.
8. « The Apache JDO web page », hosted by Apache Software Foundation,
http://db.apache.org/jdo/
9. « db4o, an object oriented datastore », http://www.db4o.com/s/linqdb.aspx
10. « Siaqodb first full Linq-supported object database », http://siaqodb.com/
11. « Linq in Action », par Fabrice Marguerie, Steve Eichert et Jim Wooley, O’Reilly Media, 2008.
12. « Bases de données », Esteban Zimànyi, cours donné en MA1 de la faculté des sciences
appliquées de l’Université Libre de Bruxelles, 2008.
13. « Forum des développeurs C# », forum de la communauté Developpez.com,
http://www.developpez.net/forums/f484/dotnet/langages/csharp/
14. « DbLinq 2007 », site du projet Db Linq, http://code.google.com/p/dblinq2007/
15. « Mono 2.6 Release Notes », site du projet Mono, partie relative à la version 2.6,
http://www.mono-project.com/Release_Notes_Mono_2.6
16. « Hibernate in Action », par Christian Bauer et Gavin King, O’Reilly.
17. « NHibernate for .NET », site hébergé par la communauté JBoss,
http://community.jboss.org/wiki/NHibernateforNET
18. « Linq to NHibernate page », http://www.hookedonlinq.com/LINQToNHibernate.ashx
19. « Doctrine ORM page », http://www.doctrine-project.org/
20. « ORM comparison and benchmark », ormeter.net/
21. « Apache Cayenne : Orm comparison for Java », https://cwiki.apache.org/CAY/ormcomparison.html
22. « eZ Publish », site du projet open-source eZ Publish, ez.no
23. « Drupal community plumbing», site de la communauté Drupal, drupal.org
24. « OpenERP », site de OpenERP anciennement tinyErp, http://www.openerp.com/

Annexe 1 : Code de l’exemple Linq to object
Contenu du fichier Ville.cs :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace exLinq
{
class Ville
{
private string nom;
private int nbrHab;
public List communes;
public List liaisons;
public Ville(string n, int nbr)
{
nom = n;
nbrHab = nbr;
communes = new List();
liaisons = new List();
}
public string Nom {get{return nom;} set{nom=value;}}
public int Hab { get { return nbrHab; } set { if(value>0) nbrHab =
value; } }
}
}
public void AjouterCommune(string nom)
{
communes.Add(nom);
}
public void RetirerCommune(string nom)
{
communes.Remove(nom);
}
public void RelierA(Ville v)
{
liaisons.Add(v);
}
public void EnleverLiaisonAvec(Ville v)
{
liaisons.Remove(v);
}

Contenu du fichier program.cs :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Text;
namespace exLinq
{
class Program
{
static void Main(string[] args)
{
Villes();
Console.Read();
}
static void Villes()
{
List reseauRoutier = InitialiseLeReseau();
var requete = from v in reseauRoutier
from c in v.liaisons
where v.communes.Count() >= 2
&& c.Hab

}
}
}
v6.RelierA(v2);
v3.RelierA(v5);
v5.RelierA(v3);
v4.RelierA(v6);
v6.RelierA(v4);
v5.RelierA(v6);
v6.RelierA(v5);
List reseau = new List();
reseau.Add(v);
reseau.Add(v2);
reseau.Add(v3);
reseau.Add(v4);
reseau.Add(v5);
reseau.Add(v6);
return reseau;
Vu les valeurs données lors de l’initialisation, on constate que « l’ensemble des villes ayant au moins
deux communes et étant connectées à au moins une ville de maximum 10000 habitants » se résume
à Braine l’Alleud, qui est la seule ville connectée à Zaventem (la seule de moins de 10000 habitants) à
posséder au moins deux communes.

Annexe 2 : Code de tests de performance pour Linq to Sql
Contenu de la classe ADOManager.cs :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Common;
using System.Data.SqlClient;
namespace Linq_demo_console_3
{
public class ADOManager
{
private SqlConnection db;
private SqlDataReader rdr;
public void Connect()
{
Console.WriteLine();
db = new SqlConnection("Data
Source=.\\SQLEXPRESS;AttachDbFilename=\"G:\\Documents and
Settings\\Charles\\Mes documents\\Visual Studio
2008\\Projects\\Linq_demo_console_3\\LinqSelectTest\\LinqDB.mdf\";Integrate
d Security=True;Connect Timeout=30;User Instance=True");
rdr = null;
try {
Console.WriteLine("ADO Initializing");
Console.WriteLine("Manual Connection to DataBase");
db.Open();
Console.WriteLine("DataSource : "+db.DataSource);
Console.WriteLine("DataBase : " + db.Database);
}
catch(Exception e)
{
Console.WriteLine(e.Message);
}
}
public void LaunchInsertTest(int charge)
{
this.Connect();
Console.WriteLine();
Console.WriteLine("*** ADO Test running ***");
//Compute Time interval required to construct query
DateTime start = DateTime.Now;
Console.WriteLine("Starting test at " + start.Hour + ":" +
start.Minute + ":" + start.Second + ":" + start.Millisecond);
string sql = "INSERT INTO
Customers(Name,Address_city,Address_zip,Address_street,Address_number)";
string sql2;
string totalQuery = "";
for(int i=1;i

DateTime qStart = DateTime.Now;
Console.WriteLine("Starting query at " + qStart.Hour + ":" +
qStart.Minute + ":" + qStart.Second + ":" + qStart.Millisecond);
SqlCommand com = new SqlCommand(totalQuery, db);
com.ExecuteNonQuery();
DateTime end = DateTime.Now;
Console.WriteLine("End of test at " + end.Hour + ":" +
end.Minute + ":" + end.Second + ":" + end.Millisecond);
Console.WriteLine("Query duration : "+(end-qStart).ToString());
Console.WriteLine("Test Duration : " + (end -
start).ToString());
this.Deconnect();
}
public void SingleQuery(int i)
{
string sql = "INSERT INTO
Customers(Name,Address_city,Address_zip,Address_street,Address_number)";
sql += " VALUES('cust" + i + "','city" + i + "','" + i +
"','street" + i + "'," + i + "); ";
SqlCommand com = new SqlCommand(sql, db);
com.ExecuteNonQuery();
}
}
}
public void Deconnect()
{
if (db != null)
db.Close();
}

Contenu de la classe LinqBenchmarking.cs :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Linq_demo_console_3
{
public class Linq_benchmarking
{
private CustomerDataContext db;
public Linq_benchmarking()
{
db = new CustomerDataContext();
}
public void LaunchInsertTest(int charge)
{
Console.WriteLine("*** LINQ Test running ***");
//Compute Time interval required to construct query
DateTime dt = System.DateTime.Now;
Console.WriteLine("Starting test at
"+dt.Hour+":"+dt.Minute+":"+dt.Second+":"+dt.Millisecond);
for (int loop = 1; loop

}
}
}
public void CleanDB()
{
var cust = from c in db.Customers
select c;
foreach (Customers cst in cust)
{
db.Customers.DeleteOnSubmit(cst);
}
db.SubmitChanges();
}
public string TimeBetween(DateTime start, DateTime end)
{
string time = "";
time += (end - start).ToString();
return time;
}
public void SingleQuery(int n)
{
Customers c = new Customers();
c.ID = n;
c.Name = "customer" + n.ToString();
c.Address_city = "city" + n.ToString();
c.Address_number = n;
c.Address_street = "street" + n.ToString();
c.Address_zip = n.ToString();
db.Customers.InsertOnSubmit(c);
//db.SubmitChanges();
}
public void Submit()
{
db.SubmitChanges();
}

Contenu de Customer.dbml :
#pragma warning disable 1591
//-------------------------------------------------------------------------
-----
//
// Ce code a été généré par un outil.
// Version du runtime :2.0.50727.3603
//
// Les modifications apportées à ce fichier peuvent provoquer un
comportement incorrect et seront perdues si
// le code est régénéré.
//
//-------------------------------------------------------------------------
-----
namespace Linq_demo_console_3
{
using System.Data.Linq;
using System.Data.Linq.Mapping;
using System.Data;
using System.Collections.Generic;
using System.Reflection;
using System.Linq;
using System.Linq.Expressions;
using System.ComponentModel;
using System;
[System.Data.Linq.Mapping.DatabaseAttribute(Name="LinqDB")]
public partial class CustomerDataContext :
System.Data.Linq.DataContext
{
private static System.Data.Linq.Mapping.MappingSource
mappingSource = new AttributeMappingSource();
#region Extensibility Method Definitions
partial void OnCreated();
partial void InsertCustomers(Customers instance);
partial void UpdateCustomers(Customers instance);
partial void DeleteCustomers(Customers instance);
#endregion
public CustomerDataContext() :
base(global::Linq_demo_console_3.Properties.Settings.Default.LinqDBCo
nnectionString, mappingSource)
{
OnCreated();
}
public CustomerDataContext(string connection) :
base(connection, mappingSource)
{
OnCreated();
}
public CustomerDataContext(System.Data.IDbConnection
connection) :
base(connection, mappingSource)

{
}
OnCreated();
public CustomerDataContext(string connection,
System.Data.Linq.Mapping.MappingSource mappingSource) :
base(connection, mappingSource)
{
OnCreated();
}
public CustomerDataContext(System.Data.IDbConnection
connection, System.Data.Linq.Mapping.MappingSource mappingSource) :
base(connection, mappingSource)
{
OnCreated();
}
}
public System.Data.Linq.Table Customers
{
get
{
return this.GetTable();
}
}
[Table(Name="dbo.Customers")]
public partial class Customers : INotifyPropertyChanging,
INotifyPropertyChanged
{
private static PropertyChangingEventArgs emptyChangingEventArgs
= new PropertyChangingEventArgs(String.Empty);
private int _ID;
private string _Name;
private string _Address_city;
private string _Address_zip;
private string _Address_street;
private System.Nullable _Address_number;
private string _Email;
#region Extensibility Method Definitions
partial void OnLoaded();
partial void OnValidate(System.Data.Linq.ChangeAction action);
partial void OnCreated();
partial void OnIDChanging(int value);
partial void OnIDChanged();
partial void OnNameChanging(string value);
partial void OnNameChanged();
partial void OnAddress_cityChanging(string value);
partial void OnAddress_cityChanged();
partial void OnAddress_zipChanging(string value);
partial void OnAddress_zipChanged();

partial void OnAddress_streetChanging(string value);
partial void OnAddress_streetChanged();
partial void OnAddress_numberChanging(System.Nullable value);
partial void OnAddress_numberChanged();
partial void OnEmailChanging(string value);
partial void OnEmailChanged();
#endregion
public Customers()
{
OnCreated();
}
[Column(Storage="_ID", AutoSync=AutoSync.OnInsert, DbType="Int
NOT NULL IDENTITY", IsPrimaryKey=true, IsDbGenerated=true)]
public int ID
{
get
{
return this._ID;
}
set
{
if ((this._ID != value))
{
this.OnIDChanging(value);
this.SendPropertyChanging();
this._ID = value;
this.SendPropertyChanged("ID");
this.OnIDChanged();
}
}
}
[Column(Storage="_Name", DbType="VarChar(50) NOT NULL",
CanBeNull=false)]
public string Name
{
get
{
return this._Name;
}
set
{
if ((this._Name != value))
{
this.OnNameChanging(value);
this.SendPropertyChanging();
this._Name = value;
this.SendPropertyChanged("Name");
this.OnNameChanged();
}
}
}
[Column(Storage="_Address_city", DbType="VarChar(50) NOT NULL",
CanBeNull=false)]
public string Address_city
{
get
{

}
}
set
{
}
return this._Address_city;
if ((this._Address_city != value))
{
this.OnAddress_cityChanging(value);
this.SendPropertyChanging();
this._Address_city = value;
this.SendPropertyChanged("Address_city");
this.OnAddress_cityChanged();
}
[Column(Storage="_Address_zip", DbType="VarChar(8) NOT NULL",
CanBeNull=false)]
public string Address_zip
{
get
{
return this._Address_zip;
}
set
{
if ((this._Address_zip != value))
{
this.OnAddress_zipChanging(value);
this.SendPropertyChanging();
this._Address_zip = value;
this.SendPropertyChanged("Address_zip");
this.OnAddress_zipChanged();
}
}
}
[Column(Storage="_Address_street", DbType="VarChar(50)")]
public string Address_street
{
get
{
return this._Address_street;
}
set
{
if ((this._Address_street != value))
{
this.OnAddress_streetChanging(value);
this.SendPropertyChanging();
this._Address_street = value;
this.SendPropertyChanged("Address_street");
this.OnAddress_streetChanged();
}
}
}
[Column(Storage="_Address_number", DbType="Int")]
public System.Nullable Address_number
{
get
{

}
}
set
{
}
return this._Address_number;
if ((this._Address_number != value))
{
this.OnAddress_numberChanging(value);
this.SendPropertyChanging();
this._Address_number = value;
this.SendPropertyChanged("Address_number");
this.OnAddress_numberChanged();
}
[Column(Storage="_Email", DbType="VarChar(50)")]
public string Email
{
get
{
return this._Email;
}
set
{
if ((this._Email != value))
{
this.OnEmailChanging(value);
this.SendPropertyChanging();
this._Email = value;
this.SendPropertyChanged("Email");
this.OnEmailChanged();
}
}
}
public event PropertyChangingEventHandler PropertyChanging;
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void SendPropertyChanging()
{
if ((this.PropertyChanging != null))
{
this.PropertyChanging(this,
emptyChangingEventArgs);
}
}
protected virtual void SendPropertyChanged(String propertyName)
{
if ((this.PropertyChanged != null))
{
this.PropertyChanged(this, new
PropertyChangedEventArgs(propertyName));
}
}
}
}
#pragma warning restore 1591

Contenu du fichier program.cs :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using MySql.Data;
using MySql.Data.MySqlClient;
namespace LinqToDataSet
{
class Program
{
static void Main(string[] args)
{
MySqlConnection con = new
MySqlConnection("Database=MyLinqSql;Uid='root';Pwd='C1$oon'");
string cmdString = "show tables";
MySqlCommand cmd = new MySqlCommand(cmdString, con);
con.Open();
MySqlDataReader dr = cmd.ExecuteReader();
Console.WriteLine("Tables présentes dans la Db :");
while (dr.Read())
{
Console.WriteLine(dr.GetValue(0));
}
//Fermeture du reader pour eviter conflit avec DataAdapter
dr.Close();
DataSet ds = new DataSet("MySqlDataSet");
string selectString = @"SELECT * FROM objects1";
MySqlDataAdapter da = new MySqlDataAdapter(selectString,con);
da.TableMappings.Add("objects1", "Table");
da.Fill(ds);
//interrogation du DataSet ds avec Linq to DataSet
DataTable dt1 = ds.Tables["Table"];
var dataSetQuery = from o in dt1.AsEnumerable()
select new {ID = o.Field("Id"), TEXT =
o.Field("Desc")};
Console.WriteLine("Requête adressée au DataSet construit depuis une
Db MySql");
}
}
}
foreach(var res in dataSetQuery)
{
Console.WriteLine(res);
}
//Fermeture de la connexion
con.Close();
Console.WriteLine("Appuyez sur Enter pour terminer...");
Console.ReadLine();

Annexe 3 : Utilisation d’une base de données MySQL avec Linq to
DataSet
Phase 1 : Création de la base de données avec MySQL
Téléchargement de MySQL Community Server (disponible à cette adresse :
http://dev.mysql.com/downloads/ ). Après installation et première configuration, lancement de
l’utilitaire MySQL en ligne de commande. Les commandes entrées sont, dans l’ordre :
Create Database MyLinqSql \g
\u MyLinqSql
Create Table objects1 ( `Id` int not null, `Desc` varchar(20) default ‘’, primary key(Id) );
Create Table objects2 ( `Id` int not null, `Code` int not null, `ShortDesc` varchar(20) default ‘’,
primary key (Id), foreign key (Code) references objects1(Id) );
Insert into objects1(`Id`,`Desc`) values (1,”description 1”); Insert into objects1(`Id`,`Desc`)
values (2,”description 2”); insert into objects1(`Id`,`Desc`) values (3,”description 3”);
Insert into objects2 values (1,1,”obj2 pointe vers 1”); Insert into objects2 values
(2,1,”obj2.2”); Insert into objects2 values (3,2,”obj2.3”); Insert into objects2 values
(4,1,”obj2.4”); Insert into objects2 values (5,2,”obj2.5”);
Ce qui doit donner comme contenu pour objects1 (Select * from objects1 ;) :
Et pour objects2 :