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

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.