L’utilisation de SaveChanges() dans Entity Framework est très fréquente, et appeler SaveChanges() après une seule modification ou suppression de données retourne le nombre d’enregistrements d’impact.
Pour utiliser la modification par lots ou la suppression par lots des données, vous avez besoin de la méthode SaveChanges(false)+AcceptAllChanges().
SaveChanges(false) est simplement une notification indiquant que l’EF doit effectuer une opération sur la base de données, qui est en attente en mémoire et peut être annulée si nécessaire, comme lorsque l’envoi d’AcceptAllChange() est vraiment réussi, et que l’EF annulera l’opération de SaveChanges(false).
Lorsqu’on traite d’opérations de transaction distribuées, il est nécessaire d’utiliser TransactionScope pour les gérer, et bien souvent nous écrivons ainsi :
Mais écrire comme ça est risqué, faux
Par exemple, contexte1. SaveChanges() réussi, context2. SaveChanges() pose problème, nous sommes dans le champ d’action. Complete() se terminera lorsque la transaction sera engagée et que Context1 aura été exécuté avec succès
(Dans ma pratique, ce qui précède peut en fait être annulé normalement, si context1. SaveChanges() réussi, context2. SaveChanges() pose problème, aucun ne sera exécuté avec succès !
Référez l’espace de noms Using System.Transaction dans votre projet. Définir un TransactionScope dans l’utilisation équivaut à définir un champ des choses, c’est-à-dire que le périmètre de cette transaction se trouve dans l’usage. Dans le champ d’utilisation, s’il n’y a pas de périmètre. Complète(), puis la lunette annulera automatiquement toutes les opérations lorsqu’elles sont détruites. ）
Cela ne répond pas forcément à nos besoins. Si nous avons besoin que context1 et context2 soient exécutés avec succès en même temps, ou si aucun ne réussit, nous devons apporter de petits ajustements au code, comme utiliser le code suivant :
Nous utilisons SaveChanges(false) pour envoyer d’abord les commandes d’opérations nécessaires à la base de données, ce qui signifie noter que context1 et context2 n’ont pas vraiment changé ; si la transaction est terminée et automatiquement annulée, aucun des deux changements n’est réellement engagé dans la base de données, ce qui permet de la revenir avec succès.
|
Publié sur 08/04/2017 22:10:01
|
|
|
