Responsabilités du développeur en matière de substitution du comportement par défaut
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
) etUpdate
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 overrideInsertOrder()
doit récupérer l’ID généré par une base de données et affecter le membreOrder.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 et ne vérifie pas 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écessite 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.