¿Deben almacenarse los objetos comerciales dinámicos para un sitio en la sesión de los usuarios o usar el almacenamiento en caché ASP.Net (objetos como pedidos, información de perfil, etc.)?Caché de datos frente a objeto de sesión en ASP.Net
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é?
Si los objetos se pueden compartir entre sesiones de usuario, utilice 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.
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 está buscando mejorar el rendimiento, sería mejor que reemplace 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á tratando de 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.
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 el almacenamiento de objetos, aunque personalmente trato de evitar el almacenamiento de sesión a favor de un DB. Yo suelo hacer que por abstraerse de la tienda detrás de una opaca ISessionStoreService interfaz:
interface ISessionStore
{
T GetEntry<T>(string key);
void SaveEntry<T>(string key, T entry);
}
y luego "dependencia de inyección de" aplicación adecuada, ya sea InmemorySessionStore, DbSessionStore o lo que sea.
Aunque puede almacenar su objeto comercial en la memoria caché, pero la memoria caché está diseñada 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 caducidad, la prioridad y la dependencia (como SqlDependency o FileDependency), por lo que para las próximas solicitudes puede usar 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).
Otra consideración sería el nivel de control y la granularidad necesarios para la duración de los datos en caché. La sesión lo limita a una estrategia de caducidad de deslizamiento basada en el período de tiempo de espera del estado de la sesión global. Usar el caché directamente le da control adicional sobre estos parámetros. –