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

More documents

Recommendations

Info

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.
Page 1 and 2: Faculté des Sciences appliquées A
Page 3 and 4: Table des matières Conventions d
Page 5 and 6: Bibliographie 51 Annexe 1 : Code de
Page 7 and 8: Introduction Depuis l’apparition
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: 3.3 Exemple illustratif Considéron
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

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

Create successful ePaper yourself

Delete template?

Save as template?