Etude exploratoire de Linq

Transcription

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

2 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.

3 Table des matières Conventions d écriture 1 Introduction 2 1. Vue d ensemble 3 2. Mécanismes sous-jacents Quelques rappels Généricité Délégués Méthodes anonymes Enrichissements syntaxiques Inférence sur le typage Expressions lambda Expressions arborescentes Extensions de méthode Formalisme d une requête Implémentation Objets Champ d application Quelques opérateurs à la loupe Projection groupée Inversion et indexes Groupement Quantificateurs Conversion en énumérable Exemple illustratif Implémentations relationnelles Entités en mémoire Linq to SQL Mapping Syntaxe au niveau du code Principe et fonctionnement Gestion par le DataContext 21

4 4.2.2 Opérations fondamentales Cas pratiques Erreurs et difficultés Performances Test d insertion Test en situation concurrentielle Conclusion Linq to DataSet Linq to Entities Concept fondateur Fonctionnement Mapping Rôlede Linq Db Linq Implémentation XML En pratique Ressenti général Points forts, points faibles Quelles alternatives? Java JDO Hibernate NET NHibernate Entity Framework Autres langages Persistance personnalisée Bases de données objets Evolutions de Linq Version Ce qui reste à améliorer Linq et Mono 49 Conclusion 50

5 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

6 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.

7 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 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.

8 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 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é.

9 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 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 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.

10 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 ) 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);

11 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] 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 ==.

12 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<int> list = new List<int>(new int[] -1, 2, -5, 45, 5 ); List<int> positivenumbers = list.findall(delegate(int i) return i > 0; ); //meme code ecrit avec une expression lambda List<int> list = new List<int>(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 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

13 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.

14 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<int, int> lambdainc = (x) => x + 1; Expression<Func<int, int>> 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.

15 Figure 3 : schéma d'une expression arborescente Pour réaliser une structure similaire, voici le code proposé : static void equivalent() Expression<Func<int, int>> exprinc; ConstantExpression constante = Expression.Constant(1, typeof(int)); ParameterExpression parametre = Expression.Parameter(typeof(int), "x"); BinaryExpression addition = Expression.Add(parametre, constante); exprinc = Expression.Lambda<Func<int, int>>(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 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.

16 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<T> 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 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 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<T> 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);

17 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<T> 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.

18 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<T> 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<T>. 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<T> 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 :

19 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 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 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<T>. 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 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.

20 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é 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 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<T>. 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.

21 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 habitants. Ceci s écrit comme suit : var petitesvilles = from v in reseauroutier where v.hab <= orderby v.hab select new Ville = v.nom ; foreach (var ville in petitesvilles.reverse()) Console.WriteLine(ville); Ce code, en plus d être intuitif, permet de réaliser aisément la récupération du résultat. Ceci n est cependant pas très dur à récupérer en utilisant une syntaxe classique. Imaginons maintenant vouloir connaître l ensemble des villes qui comprennent au moins deux communes et qui sont connectées à une ville de moins de habitants. Avec une écriture classique, cela implique de parcourir la liste des villes du réseau. Pour chacune de ces villes, il faudra récupérer l ensemble des communes et les dénombrer. Pour celles qui possèdent au moins deux communes, il faudra parcourir la liste des villes avec lesquelles une connexion existe. Si les villes à l autre bout de cette connexion ont un nombre d habitant inférieur ou égal à la borne souhaitée, nous devons ajouter la ville initiale à l ensemble qui sera le résultat. C est déjà relativement complexe à écrire en syntaxe classique, mais si nous désirons maintenant montrer le nom des villes à faible population qui figurent dans les connexions, c est encore pire. Il faudra créer des associations voire même recréer un graphe d objets et le retourner comme résultat. Ecrivons cela avec Linq : var requete = from v in reseauroutier from c in v.liaisons where v.communes.count() >= 2 && c.hab <= select new Ville = v.nom, Connexion = c.nom, Habitants=c.Hab; foreach (var v in requete) Console.WriteLine(v);

22 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.

23 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.