Meilleures pratiques et modèles de cache de session d'application ASP.net

Question

Dans asp.net, les principaux magasins de données sont l'application, la session et le cache d'objets. J'ai utilisé des trucs et astuces de bon sens (par exemple, ne jamais mettre de données spécifiques aux utilisateurs dans l'application, ne jamais mettre de ressources non gérées en session, etc.) mais pour être honnête je n'ai jamais trouvé de recommandations ou des personnalités comme Haack et Gu qui couvrent les trois ensemble (par exemple, le premier hit de Google à MSDN parle d'utiliser l'application comme cache global, si c'est le cas, à quoi sert le cache d'objet?). rarement discuté est la comparaison dans le scénario, par exemple je sais qu'il est facile de charger la mémoire inutile avec l'utilisation de la session, mais que se passe-t-il si vous avez utilisé le cache objet comme une alternative pour stocker les mêmes données? est l'être st informations que j'ai trouvées jusqu'à maintenant: http://msdn.microsoft.com/en-us/library/ff647787.aspx

Answer 1

Utilisez Session pour stocker des informations spécifiques à l'utilisateur, car le framework associe automatiquement chaque magasin de session à un utilisateur spécifique.

Utilisez le cache d'objets pour obtenir des informations qui peuvent être mises en cache une fois et réutilisées dans l'ensemble de l'application ou sur un ensemble d'utilisateurs. Si vous stockez des données spécifiques à l'utilisateur dans le cache d'objets, vous devrez inventer un mécanisme pour associer les entrées de cache. Non seulement cela nécessiterait un travail supplémentaire en votre nom, mais vous pourriez le faire d'une manière qui augmente la probabilité qu'un utilisateur infâme fasse quelque chose comme l'usurpation de session.

Je ne sais pas quand vous aurez besoin d'utiliser l'objet Application. Si je ne me trompe pas, l'objet Application est plus une relique de l'ASP classique qu'autre chose.

Une autre forme de mise en cache qui peut être tout aussi importante est la mise en cache par requête via la collection HttpContext.Items. Cela vous permet de mettre en cache des données pour la durée de vie d'une requête et est utile si vous continuez à demander les mêmes données lors d'une seule requête (par exemple, à partir de différents contrôles utilisateur sur la page). Pour plus d'informations sur cette approche, voir HttpContext.Items - a Per-Request Cache Store.

Answer 2

Je suggère de créer une classe wrapper, au moins pour la session, si ceux-ci sont utilisés dans votre code. De cette façon, vous pouvez injecter une instance de la classe pour faire le vrai travail, et utiliser une version simulée pour les tests unitaires. Je l'ai fait pour un grand projet où la session était largement utilisée, et ça a plutôt bien marché.

Vous pouvez combiner ceci avec le modèle de façade - l'encapsuleur fournira des méthodes spécifiques dont vous avez besoin, au lieu d'exposer l'interface générale. A titre d'exemple, la session prend des objets et retourne des objets, elle n'est pas fortement typée. Le wrapper peut avoir des méthodes add et get fortement typées.