¿Por qué debo o no debo almacenar un Dataset, Datatable, etc. como una variable de sesión en una página ASP.NET?

Question

Estoy trabajando en una aplicación web que consume un conjunto de datos devuelto por un servicio web.

Como la aplicación se está ejecutando, almaceno ese Dataset como una variable de sesión que se utilizará una y otra vez a medida que el usuario navega a las diferentes páginas que editarán las tablas dentro del conjunto de datos.

La idea era que el usuario solo tendría que esperar los datos una vez cuando se carga la aplicación, entonces la aplicación usaría la variable de sesión hasta que el usuario guarde los cambios realizados, cuando eso pase pasará las tablas editadas al servicio para actualizar la base de datos.

¿Hay problemas con este diseño y el almacenamiento del Dataset y Datatables como una variable de sesión? Pros y contras házmelo saber.

Answer 1

La única ventaja es:

• Es más rápido que ir varias veces a su base de datos. Dicho esto, las bases de datos de Enterprise hacen suficiente almacenamiento en caché que a menudo no es necesario.

Los contras son legión, pero los tres principales serían:

• Si los datos se cambia de otra sesión (por ejemplo un usuario administrador), Sesión de su usuario no sabe
• asignación de memoria puede ser un problema grave muy rápidamente (aunque esto puede aliviarse usando Caché en lugar de Session y tecleando Session ID)
• Si alguna vez se muda a una granja de servidores, tendrá que replantear todo su diseño, muy posiblemente usando el DB para almacenar Datos de Sesión - entonces su argumento de eficiencia va a parecer un poco débil

[Editar] Como otros han señalado, también hay un problema con guardar cualquier cosa en la sesión o caché (o en menor medida la aplicación) sin persistir en algún lugar más permanente también. Si una sesión caduca o incluso se reinicia (he visto configuraciones de hardware que hacen que la sesión comience y termine con cada solicitud. Aunque conserva la ID de sesión, se pierde cualquier dato almacenado en los objetos de sesión. Si la aplicación se reinicia para lo que sea Por supuesto, todos los objetos de la sesión, la caché y la aplicación se borran. Los objetos de caché pueden borrarse en cualquier momento, solo porque el entorno decida que quiere ese espacio de memoria para otra cosa.

En resumen: este no es el camino para ir.

Si necesita que el usuario pueda realizar cambios y luego presionar Guardar para conservarlos, mantenga un conjunto separado de tablas de estado que detallen los cambios que se deben realizar en las tablas principales cuando el usuario toque Guardar . Almacenar una cookie en el cliente con una clave que expira un largo camino hacia el futuro; use esa cookie para unir sus datos de estado al usuario.

Answer 2

Big con: DataSets son enormes, por lo que mantenerlos en la memoria del servidor es un problema, especialmente cuando la cantidad de usuarios comienza a crecer.

Answer 3

¿Los datos son específicos del usuario? De lo contrario, terminará almacenando "usuarios no conectados" multiplicados por la tabla de datos. Puede ser que pueda usar algún tipo de mecanismo de caché, si le preocupa la latencia.

Answer 4

Mantener demasiado en la sesión tiene los riesgos que:

• Muchos usuarios, cada uno con una gran sesión requerirá más recursos del servidor.
• Si la sesión del usuario caduca (por ejemplo, interrupción de una llamada de este tipo), todo su estado se perderá y tendrá que volver a iniciar el proceso. Almacenar sus datos mientras se mueve a través de las páginas web puede resultar en una experiencia más placentera si decide continuar más adelante.

Si tiene que almacenar algo en la sesión, para hacer lo que describió quizás considere un tipo específico para este fin en lugar de un Dataset genérico o DataTable.