MS SQL Server
  1. MS SQL Server
  3. EF interroge la database à chaque fois
Intereting Posts
Insertion conditionnelle d'loggings dans une table dans un environnement multithread basé sur un nombre Comment afficher l'icône de rapport dans Firefox pour le contrôle Afficheur de rapports SQL Server Reporting Services Obtenir le résultat en fonction de la valeur de l'atsortingbut de la colonne Oracle vers SQL Server: mois + année où clause Comment build une requête pour changer la sortie d'une table sql Est-il possible d'get Cluster -> Disponibilité Node Map Instance Map via WMI? Convertir le résultat de la ligne en colonnes Syntaxe pour identity-insert FROM sans colonnes à insert? Déployer un rapport avec SSDT 2016 génère une erreur comment passer la variable ref à une procédure SQL stockée en utilisant ADO.NET? SQL OUTER JOIN avec NEWID pour générer des données randoms pour chaque ligne MSSQL cast ( à int) dans SELECT est exécuté avant que la clause WHERE ne filter les mauvaises valeurs Que fait "%% DatabaseEx" dans TSQL? Logiciel en tant que service – Base de données Indexation avec MD5 dans SQL Server

EF interroge la database à chaque fois

J'ai un context de données unique (créé une fois), et je l'utilise pour get le même logging de database plusieurs fois, par exemple, j'obtiens le même logging de produit spécifiant le même ID de produit.

Chaque fois que j'appelle, disons, context.Products.Single(p => p.ProdID == 1) , le context renvoie la même instance de l'entité produit, MAIS interroge la database à chaque fois, ce qui est visible dans SQL Server Profiler.

Je vérifie qu'il renvoie la même instance en modifiant certaines propriétés entre les appels. L'appel suivant renvoie l'instance avec les propriétés modifiées.

Pourquoi interroge-t-on la database à chaque fois, et existe-t-il un moyen d'éviter cela?

Vous pouvez utiliser ObjectContext.GetObjectByKey ( DbSet<T>.Find pour DbContext ) pour interroger une entité à l'aide de sa key. Cette méthode vérifie si l'object avec la key spécifiée est déjà attaché au context. Si oui, il returnnera cet object sans interroger la database. S'il n'existe pas dans le context, il lance une requête de database.

Les requêtes LINQ interrogent généralement la database, que les objects soient déjà attachés au context ou non. EF ne peut pas savoir à l'avance si les objects sont attachés ou non car il ne connaît pas le résultat de la requête. Votre requête LINQ par key est une exception – théoriquement – car EF peut savoir si la requête est nécessaire ou non car elle peut vérifier si l'object avec cette key est déjà attaché. Mais cette exception n'est pas gérée en tant que telle – c'est pourquoi GetObjectByKey existe – et interroge la database comme toutes les autres requêtes LINQ.

Ce qui se passe avec le résultat de la requête est déterminé par MergeOption de l'object ObjectSet. La valeur par défaut est AppendOnly ce qui signifie que le résultat de la requête est rejeté si un object avec la key est déjà attaché au context. Rien n'est écrasé ou actualisé par la requête. Seulement si un object avec la key n'existe pas dans le context, un object du résultat de la requête est matérialisé et sera attaché au context. Vous pouvez modifier ce comportement par défaut en choisissant un autre MergeOption .

Il le fait parce qu'un autre user peut avoir modifié l'logging entre le premier et le deuxième appel.

Envisagez une solution de caching si datatables sont relativement statiques.