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

l’ancienne valeur dans chaque relation à laquelle elle participe. Notons également que les mises à
jour sont les seules opérations pouvant être invisibles au programmeur inattentif. Dans le cadre
d’une relation entre entités, s’il l’un des participants est supprimé l’autre subira une mise à jour pour
refléter que cette relation n’existe plus [4] [11]. Cette mise à jour n’aura éventuellement pas été
spécifiée explicitement. De même, lorsqu’une association est créée en passant à une entité une
référence vers une autre entité, l’entité reliée (mais non modifiée explicitement) sera mise à jour.
Ajouter ou modifier une entité du DataContext n’est en soi que la moitié du travail. Les entités en
mémoire ne sont plus synchronisées par rapport à la base de données et les modifications désirées
n’y seront pas encore effectives [1]. Pour notifier le DataContext qu’une mise à jour est souhaitée, il
faut le faire explicitement par le biais de la méthode SubmitChanges. Cette opération va prendre en
charge toutes les modifications apportées aux entités, qu’il s’agisse de créations, de mises à jour ou
de suppressions. C’est lors de l’appel de cette méthode que le service sentinelle va répertorier toutes
les modifications apportées aux entités. Des instructions Sql vont ensuite être générées pour amener
la base de données correspondant aux entités en mémoire. Ceci a plusieurs implications en termes
de performances et d’ordonnancement des opérations. Premièrement, chaque appel de la méthode
SubmitChanges peut potentiellement donner lieu à des opérations inattendues à cet instant précis
[4]. En effet, la sentinelle enregistre toutes les modifications et il est tout à fait possible qu’une autre
partie du programme ait créé des modifications entre une insertion et sa soumission quelques lignes
plus loin. Dans un contexte multithreads ou dans celui d’une programmation par événements,
l’enchaînement exact de chaque instruction est au mieux dur à prévoir. Les mises à jour implicites
sont également à ranger dans cette catégorie d’opérations fantômes. Deuxième remarque à
soulever, le service sentinelle passe en revue chaque entité en mémoire à chaque appel de cette
fameuse méthode. La seule opération effectuée sur une entité non modifiée consiste à tester si son
marquage est toujours égal à « non modifiée ». Pour un ensemble conséquent d’entités, ceci peut
créer un délai non désiré dont il faut rester conscient. Il est, par exemple, conseillé d’éviter d’appeler
SubmitChanges dans une boucle destinée à créer un ensemble d’objets.
4.2.3 Cas pratiques
Il nous reste maintenant à découvrir les techniques pratiques pour construire un mapping et son
DataContext associé. Nous allons ensuite soumettre quelques requêtes et observer comment nous
parviennent les résultats. Nous envisagerons d’abord un cas très simple à vocation illustrative avant
de considérer des scénarios plus complexes.
Supposons que nous ayons une base de données Sql Server 2008 pleinement fonctionnelle à notre
disposition et que notre application ne souhaite pas prendre en charge les accès concurrentiels pour
l’instant. Nous allons réaliser tout cela avec Visual Studio 2008, étape par étape.
En ayant créé un nouveau projet C#, nous allons ouvrir l’explorateur de serveurs pour y localiser
notre base de données. Lorsque nous l’avons trouvée, nous pouvons désormais voir les tables qu’elle
contient, ses procédures stockées, ses fonctions utilisateurs, les associations entre les tables et de
nombreuses autres informations dont nous ne ferons pas usage dans ce simple petit test. Ajoutons
une classe à notre projet dont le type sera « Linq to Sql class ». Les classes Linq to Sql arborent
l’extension Dbml, aussi nous pouvons en conclure qu’il s’agira de notre fichier de mapping.
Choisissons lui un nom de circonstance (par exemple « MonMapping ») et validons notre choix afin
de créer ce fameux fichier de mapping. Rappelons que la structure d’un tel fichier, vue à la section