¿Cuántos datos puede/debe almacenar en un objeto de sesión de usuarios?

Question

Tenemos varias aplicaciones de formulario de estilo asistente en nuestro sitio web donde capturamos información del usuario en cada página y luego la enviamos a un proceso de back-end utilizando un servicio web.

Desafortunadamente, no podemos enviar la información en fragmentos durante cada envío del formulario, así que tenemos que almacenarla en la sesión de los usuarios hasta el final del proceso y enviarla al mismo tiempo.

¿La cantidad de memoria del servidor/espacio en disco del servidor sql es la única restricción sobre cuánto puedo almacenar en las sesiones de los usuarios o hay algo más que deba tener en cuenta?

Editar: El sitio está construido en formularios web ASP.NET.

Answer 1

Suponiendo que la información no es confidencial, entonces podría almacenar la información en una cookie que reduciría la cantidad de información requerida para ser almacenada en el servidor. Esto también le permitiría acceder a la información a través de JavaScript.

Como alternativa, puede usar viewstate para almacenar la información, aunque esto puede ocasionar que se envíen grandes cantidades de datos entre el servidor y el cliente y no sea mi solución preferida.

La cantidad de información de la sesión se debe almacenar varía enormemente dependiendo de la aplicación, el número de usuarios previstos, la especificación del servidor, etc. Para dar una respuesta más precisa requeriría más información :)

Por último, en el supuesto de que la información No se requiere recopilar todo el proceso de una página a otra, entonces podría almacenar toda la información en una tabla de base de datos y solo almacenar los registros de identificación única en la sesión. A medida que se envía cada página, se actualiza el registro de db y luego, en la página final, se recupera y envía toda la información. Esta no es una solución idea si necesita recuperar información previa en cada página subsiguiente debido al número de lecturas de DB requeridas.

Answer 2

Si usa un modelo HTTP tradicional (es decir, no usa runat = "servidor") puede publicar los datos en otra página asp y colocar los datos publicados en elementos de formulario ocultos, puede hacerlo por cuantas páginas Necesitas evitar colocar algo en una variable de sesión.

Answer 3

También podría tener 1 página ASP con todo el formulario HTML, y ocultar partes de él hasta que el relleno de usuario y "somete" la parte visible ...

entonces simplemente ocultar la parte que está llenada y muestre la siguiente parte del formulario ...

Esto sería extremadamente fácil en el marco .NET, use paneles para cada "paso del asistente" y agregue la lógica para mostrar y ocultar cada panel.

tendrá todos los datos en una sola página.

Answer 4

Dado que es problemático desde el punto de vista del rendimiento almacenar grandes cantidades de datos en el objeto Session del usuario, ASP.Net proporciona algunas otras soluciones adicionales a las mencionadas en las publicaciones anteriores. ASP.NET Profile Provider le permite persistir información relacionada con la sesión en una base de datos. También puede usar Session State Server que usa un servidor separado para almacenar toda la información de la sesión. Ambas situaciones tienen en cuenta si necesita utilizar clústeres o balanceadores de carga, los servidores aún pueden reconocer la información de la sesión en diferentes servidores. Si almacena información en el objeto Http Session, se encontrará con el problema de que un usuario siempre debe ir al mismo servidor para esa sesión.

Answer 5

Session, viewstate, base de datos.Estos son todos lentos pero harán el trabajo.

Campos de formulario ocultos es la respuesta que más me gusta.

Existen otras formas de conservar el estado. Cookies, ventana emergente, conjunto de marcos o iframes.