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

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.