c# - mvc - Caché de datos vs objeto de sesión en ASP.Net
session variable c# (5)
¿Deben almacenarse los objetos comerciales dinámicos para un sitio en la sesión de los usuarios o usar el almacenamiento en caché de ASP.Net (objetos como pedidos, información de perfil, etc.)?
He trabajado con sitios que usaban sesiones para almacenar objetos de negocios, pero me preguntaba ... ¿Cuáles son las ventajas o desventajas del almacenamiento en caché?
El almacenamiento en caché es solo eso: almacenamiento en caché. Nunca puede confiar en que las entradas estén allí, por lo que no se deben hacer suposiciones al respecto: prepárese para ir directamente al DB (o a cualquier otro lugar) para volver a buscar datos.
La sesión, por otro lado, es más adecuada para almacenar objetos, aunque personalmente trato de evitar el almacenamiento de sesión a favor de un DB. Normalmente hago eso abstrayendo la tienda detrás de una interfaz opaca de ISessionStoreService :
interface ISessionStore
{
T GetEntry<T>(string key);
void SaveEntry<T>(string key, T entry);
}
y luego la implementación apropiada de "inyección de la dependencia", ya sea InmemorySessionStore , DbSessionStore o lo que sea.
El caché del sistema ASP.NET es global para la aplicación, ya que la sesión es única para el usuario actual. Si elige usar la caché global para almacenar objetos, necesitará crear una estrategia de identificación de objetos para poder obtener los objetos correctos por usuario.
Si busca mejorar el rendimiento, sería mejor reemplazar el estado de la sesión ASP.NET con una memoria caché distribuida, como la velocidad de Microsoft. Microsoft ha publicado artículos sobre cómo reemplazar el uso de la sesión para apuntar a Velocity. También podría usar Memcache u otros productos similares de una manera relacionada.
Los objetos de sesión son adecuados para datos de solo usuario; por otro lado, los objetos de caché son más adecuados para los datos compartidos para la aplicación.
La clave para guardar en uno u otro es determinar si lo que está intentando almacenar será información de solo usuario o si debe compartirse en toda la aplicación.
Session => Una página web con una interfaz paso a paso (una prueba en línea, por ejemplo).
Caché => La información que se muestra en algún tipo de widget meteorológico (como el que google tiene en su página igoogle.com).
Espero que esto ayude.
Si los objetos se pueden compartir entre sesiones de usuario, entonces use la memoria caché. Si los objetos son únicos para cada sesión, quizás porque están gobernados por permisos, entonces guárdelos en la sesión. La sesión en proceso misma se almacena en la caché, por lo que el factor decisivo debería ser el alcance de los datos.
Aunque puede almacenar su objeto comercial en Caché, pero el caché está diseñado para mejorar el rendimiento, no para administrar el estado. Imagínese que tiene un proceso de obtener 1000 registros de la base de datos (y tarda unos 3 segundos) y lo necesitará durante unos minutos. Puede almacenar sus objetos en Caché y establecer la fecha de vencimiento, la prioridad y la dependencia (como SqlDependency o FileDependency), por lo que para las siguientes solicitudes puede utilizar los datos almacenados en caché en lugar de recuperarlos de la base de datos. Puede almacenar su objeto en Session pero no puede establecer la dependencia para Session de manera predeterminada. Además, Cache tiene un comportamiento único que cuando el sistema necesita memoria liberará objetos de la memoria caché dependiendo de su prioridad. Los objetos de caché son globales para la Aplicación y se comparten entre todos los usuarios, pero la Sesión no se comparte y es utilizable para cada usuario (Sesión).