LINQ to SQL - Comment les procédures stockées Interagir avec les changements unsubmited de DataContext?

Question

Quelqu'un ici a demandé:

"LINQ to Sql permet d'appeler SPs. Si ce SP exécute une mise à jour / suppression insert /, dois-je SubmitChanges () après?"

Et la réponse était:

« Non, vous n'avez pas. Le code fonctionnera. Soumettre les modifications est seulement concerné par LINQ modifié pour les objets SQL et ne sont pas stockées procs. »

Je voudrais simplement préciser:

(S'il vous plaît excusez-moi, je suis relativement nouveau à LINQ)

Oui, mais pas une procédure stockée dérivation l'objet DataContext et de modifier la base de données elle-même? (Alors que LINQ modifie l'objet datacontext uniquement, jusqu'à ce que la méthode est appelée DataContext.SubmitChanges, où il modifie ensuite la base de données)

Puis-je avoir une procédure stockée modifier mon objet DataContext en quelque sorte? Est-ce le font déjà?

Puis-je avoir pour que

• si je l'appelle un SP avec LINQ (et je suppose qu'il modifie directement la base de données),
• puis utilisez LINQ pour modifier mon objet DataContext et soumettre les modifications que j'ai fait à mon objet DataContext,

les deux changements différents que j'ai fait (une avec la SP, l'autre avec Linq à mon datacontext) ne gêneront pas?

Ce que je veux vraiment est un moyen d'avoir mes procédures stockées modifier ma datacontext. Est-ce possible?

Je dois mentionner que je suis la conversion d'un site de SQL à LINQ qui a principalement procédures stockées et en essayant de choisir mes batailles avec lesquelles des procédures stockées pour convertir en LINQ et qui pour rester en SQL et juste faire des appels SP à eux avec LINQ.

Merci pour votre aide, -Jeff

Answer 1

FWIW, notre test décisif est tout type 'crud' trivial PROC qui insère / met à jour un seul enregistrement peut se déplacer à travers un ORM

Cependant, nous avons tendance à laisser les procs plus avancés (mises à jour par lots, ou ceux qui sont très sensibles à la performance) « tel quel ».

Mais oui, vous aurez besoin d'avoir appelé SubmitChanges () avant d'appeler un Proc qui dépend de l'état des données modifiées dans le DataContext

Peut-être sans rapport, si vous avez besoin d'unités de contrôle du travail, regardez autour de mettre TransactionScopes votre code?

Answer 2

Si vous mettez à jour les enregistrements via procédure stockée, vos objets chargés (et chenillés) peuvent devenir obsolètes. Si vous appelez SubmitChanges avec des objets obsolètes, vous obtiendrez des exceptions de concurrence. Vous pouvez actualiser un objet ancien en utilisant la méthode Refresh sur DataContext.