Responsabilités du développeur en matière de substitution du comportement par défaut (LINQ to SQL)
LINQ to SQL n'applique pas les spécifications suivantes, mais le comportement n'est pas défini si ces spécifications ne sont pas respectées.
La méthode de substitution ne doit pas appeler SubmitChanges ou Attach. LINQ to SQL lève une exception si ces méthodes sont appelées dans une méthode override.
Les méthodes override ne peuvent pas être utilisées pour démarrer, valider ou arrêter une transaction. L'opération SubmitChanges est effectuée dans le cadre d'une transaction. Une transaction imbriquée interne peut interférer avec la transaction externe. Les méthodes override de charge peuvent démarrer une transaction uniquement après avoir déterminé que l'opération n'est pas effectuée dans un Transaction.
Les méthodes override sont supposées suivre le mappage d'accès concurrentiel optimiste applicable. La méthode override est supposée lever un ChangeConflictException lorsqu'un conflit d'accès concurrentiel optimiste se produit. LINQ to SQL intercepte cette exception afin que vous puissiez traiter correctement l'option SubmitChanges fournie sur SubmitChanges.
Les méthodes override de création (Insert) et Update sont supposées renvoyer les valeurs des colonnes générées par une base de données aux membres d'objet correspondants lorsque l'opération réussit.
Par exemple, si Order.OrderID est mappé à une colonne d'identité (clé primaire Autoincrement), la méthode override InsertOrder() doit récupérer l'ID généré par une base de données et affecter le membre Order.OrderID à cet ID. De la même façon, les membres d'horodatage doivent être mis à jour aux valeurs d'horodatage générées par une base de données afin de vérifier que les objets mis à jour sont cohérents. Si les valeurs générées par une base de données ne peuvent pas être propagées, cela peut entraîner une incohérence entre la base de données et les objets suivis par le DataContext.
L'utilisateur doit appeler l'API dynamique appropriée. Par exemple, dans la méthode override de mise à jour, seule la méthode ExecuteDynamicUpdate peut être appelée. LINQ to SQL ne détecte pas ni ne vérifie si la méthode dynamique appelée correspond à l'opération applicable. Les résultats ne sont pas définis si une méthode inapplicable est appelée (par exemple, ExecuteDynamicDelete pour un objet à mettre à jour).
Enfin, la méthode de substitution est supposée effectuer l'opération énoncée. La sémantique des opérations LINQ to SQL telles que le chargement hâtif, le chargement différé et SubmitChanges nécessitent que les substitutions fournissent le service indiqué. Par exemple, si une substitution de charge retourne simplement une collection vide sans vérifier le contenu dans la base de données, cela peut entraîner des incohérences au niveau des données.
Voir aussi
Autres ressources
Personnalisation des opérations d'insertion, de mise à jour et de suppression (LINQ to SQL)