Quelle est la différence.AsNoTracking () make?
j'ai une question concernant l'extension .AsNoTracking() , car tout cela est tout à fait nouveau et assez confus.
j'utilise un contexte par demande pour un site web.
beaucoup de mes entités ne changent pas, donc n'ont pas besoin d'être suivies, mais j'ai le scénario suivant où je ne suis pas sûr de ce qui va à la base de données, ou même si cela fait une différence dans ce cas.
Cet exemple est ce que je fais actuellement:
context.Set<User>().AsNoTracking()
// Step 1) Get user
context.Set<User>()
// Step 2) Update user
il s'agit de la même chose que ci-dessus, mais en enlevant le .AsNoTracking() de L'Étape 1:
context.Set<User>();
// Step 1) Get user
context.Set<User>()
// Step 2) Update user
les étapes 1 et 2 utilisent le même contexte mais se produisent à des moments différents. Ce que je ne peux pas savoir est de savoir si il y a une différence. Comme L'Étape 2 est une mise à jour, je suppose que les deux vont frapper la base de données deux fois de toute façon.
est-ce que quelqu'un peut me dire quelle est la différence?
6 réponses
la différence est que dans le premier cas, l'utilisateur récupéré n'est pas suivi par le contexte.ainsi, lorsque vous voulez sauvegarder l'utilisateur dans la base de données, vous devez l'attacher et régler correctement l'état de l'utilisateur de sorte que EF sache qu'il doit mettre à jour l'utilisateur existant au lieu d'en insérer un nouveau. Dans le second cas, vous n'avez pas besoin de le faire si vous chargez et enregistrez l'utilisateur avec la même instance de contexte parce que le mécanisme de suivi gère cela pour vous.
voir cette page Entity Framework and AsNoTracking
Ce AsNoTracking Ne
Entity Framework expose un certain nombre d'options de réglage des performances pour vous aider à optimiser les performances de vos applications. Une de ces options de réglage est .AsNoTracking() . Cette optimisation permet de dire Entity Framework de ne pas suivre les résultats d'une requête. Cela signifie que Entity Framework n'effectue aucun traitement ou stockage supplémentaire des entités qui sont retournés par la requête. Cependant, cela signifie également que vous ne pouvez pas mettre à jour ces entités sans rattachement au suivi graphique.
il y a des gains de performance importants à obtenir en utilisant le cumul
Pas de Suivi des requêtes LINQ to entities
L'utilisation de NoTracking () est recommandée lorsque votre requête est destinée aux opérations de lecture. Dans ces scénarios, vous récupérez vos entités mais elles ne sont pas suivies par votre contexte.Cela garantit une utilisation minimale de la mémoire et une performance optimale
Pros
- amélioration des performances par rapport aux lignes régulières requête.
- objets entièrement matérialisés.
- le plus simple à écrire avec une syntaxe intégrée dans la programmation langue.
Cons
- ne convient pas aux opérations de la CUD.
- certaines restrictions techniques, telles que: Les requêtes de jointure externe donnent lieu à des requêtes plus complexes que les requêtes externes simples. Joindre les énoncés dans Entity SQL.
- vous ne pouvez toujours pas utiliser comme avec la correspondance générale de motif.
plus d'info disponible ici:
désactiver le tracking va également causer vos ensembles de résultats à être streamé dans la mémoire. C'est plus efficace lorsque vous travaillez avec de grands ensembles de données et n'ont pas besoin de l'ensemble de données à la fois.
, les Références:
AsNoTracking () permet de contourner l'exigence de "clé unique par enregistrement" dans EF (non mentionnée explicitement par d'autres réponses).
ceci est extrêmement utile quand on lit une vue qui ne supporte pas une clé unique parce que peut-être certains champs sont nulles ou la nature de la vue n'est pas indexable logiquement.
pour ces cas, la "clé" peut être définie à n'importe quelle colonne non-nullable mais AsNoTracking () doit être utilisé avec chaque requête les enregistrements (duplicata par clé) seront omis.
si vous avez quelque chose d'autre modifiant la base de données (par exemple un autre processus) et que vous devez vous assurer de voir ces changements, utilisez AsNoTracking() , sinon EF peut vous donner la dernière copie que votre contexte avait à la place, il est donc bon d'utiliser Habituellement un nouveau contexte chaque requête:
http://codethug.com/2016/02/19/Entity-Framework-Cache-Busting /