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

More documents

Recommendations

Info

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.
Page 1 and 2: Faculté des Sciences appliquées A
Page 3 and 4: Table des matières Conventions d
Page 5: Bibliographie 51 Annexe 1 : Code de
Page 9 and 10: Chapitre 2 : Mécanismes sous-jacen
Page 11 and 12: Etudiants désignant une collection
Page 13 and 14: fait appel et l’idée est ici que
Page 15 and 16: Pour réaliser une structure simila
Page 17 and 18: A noter que etudiants n’a pas ét
Page 19 and 20: 3.2 Quelques opérateurs à la loup
Page 21 and 22: 3.3 Exemple illustratif Considéron
Page 23 and 24: Chapitre 4 : Implémentations relat
Page 25 and 26: comme gestionnaire des objets entit
Page 27 and 28: 4.2.2 Opérations fondamentales Nou
Page 29 and 30: précédente, est assez complexe et
Page 31 and 32: mapping peut-être effectué par un
Page 33 and 34: sont propres. La plupart des except
Page 35 and 36: Linq se paient par une hausse cons
Page 37 and 38: Figure 8 : tests en situation concu
Page 39 and 40: using MySql.Data; using MySql.Data.
Page 41 and 42: ase de données. Chaque fournisseur
Page 43 and 44: 4.4.4 Rôle de Linq En plus de tous
Page 45 and 46: Une particularité de l’implémen
Page 47 and 48: et plus abstrait vis-à-vis des don
Page 49 and 50: Declarative JDOQL : Query query = p
Page 51 and 52: Framework est une solution envisage
Page 53 and 54: 6.4 Evolutions de Linq Nous allons
Page 55 and 56: Conclusion Nous avons vu quels éta
Page 57 and 58:
Annexe 1 : Code de l’exemple Linq
Page 59 and 60:
} } } v6.RelierA(v2); v3.RelierA(v5
Page 61 and 62:
DateTime qStart = DateTime.Now; Con
Page 63 and 64:
} } } public void CleanDB() { var c
Page 65 and 66:
{ } OnCreated(); public CustomerDat
Page 67 and 68:
} } set { } return this._Address_ci
Page 69 and 70:
Contenu du fichier program.cs : usi
show all

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

Create successful ePaper yourself

Delete template?

Save as template?