Explication du tampon / cache dapper

.net caching dapper

Question

J'utilise dapper pour renvoyer des objets de ma base de données sous le nom IEnumerable. Par défaut, dapper a le paramètre de tampon défini sur true.

Comment cela marche-t-il?

Si dapper cache la première requête, puis récupère les objets de la mémoire.

Que se passe-t-il si quelqu'un modifie / supprime / ajoute des lignes dans la table. Dapper doit-il remettre en cache toutes les données pour cette requête?

Réponse acceptée

Le tampon n'est pas lié au cache. Dapper n'inclut aucun type de cache de données (même s'il possède un cache lié au traitement des commandes, c.-à-d. "Cette chaîne de commande, avec ce type de paramètre, et ce type d'entité - a ces méthodes générées dynamiquement à configurer) la commande et remplir les objets ").

Ce que signifie réellement ce commutateur est:

  • false : itère les éléments tels qu'ils sont reçus / consommés - en gros, un bloc itérateur autour d'un IDataReader
    • moins: vous ne pouvez l'itérer qu'une seule fois (sauf si vous êtes heureux de relancer la requête)
    • de plus: vous pouvez parcourir des requêtes immenses (plusieurs millions de lignes), sans avoir besoin de toutes les mémoires en même temps - puisque vous ne regardez vraiment que la ligne en cours
    • plus: vous n'avez pas besoin d'attendre la fin des données pour commencer à itérer - dès qu'il y a au moins une ligne, vous êtes prêt à partir
    • moins: la connexion est en cours d'utilisation lors de l'itération, ce qui peut conduire à "il y a déjà un lecteur ouvert sur la connexion" (ou peu importe le libellé exact) des erreurs si vous essayez d'invoquer d'autres commandes par ligne base (ceci peut être atténué par MARS)
    • moins: parce que le consommateur peut faire tout ce qu'il veut par élément (cela peut prendre quelques minutes par ligne, s'il fait quelque chose de complexe), la commande / lecteur peut être ouverte plus longtemps
  • true (valeur par défaut): les données sont entièrement consommées dans une List<T> avant de vous le rendre
    • plus: vous pouvez le parcourir autant de fois que vous le souhaitez
    • moins: si la requête est immense, les charger tous en mémoire (dans une liste) pourrait être coûteux / impossible
    • moins: si la requête est volumineuse, il peut y avoir une latence notable lors de la collecte de la dernière ligne
    • plus: une fois que vous obtenez les données, la commande est terminée - il n'y a donc pas de conflit entre cela et les opérations suivantes
    • plus: dès que vous obtenez les données, la commande a déjà libéré des ressources (verrous, etc.), vous avez donc un impact minimal sur le serveur

La plupart des requêtes ne renvoient qu'une quantité modérée de données (par exemple moins de 100 enregistrements). Nous sommes donc heureux que la valeur par défaut ( true ) donne le comportement le plus approprié pour la plupart des scénarios. Mais nous mettons l’option à votre disposition pour répondre à différents scénarios d’utilisation.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi