ASP.NET State Management en situaciones apropiadas

Question

Hay 6 técnicas para administrar estados en ASP.NET 3.5 (hasta donde yo sé).

(1) View State 
(2) Cross Page Posting 
(3) Query String 
(4) Session State 
(5) Application State 
(6) Cookies 

¿Alguien me puede dar algunos ejemplos apropiados de situaciones en las que debería utilizar estas técnicas?

Por ejemplo:

(*) Session State: Personalization, Buy Cart, etc. 
(*) Cookies: Saving User Credentials, etc. 

Answer 1

gestión estatal opción

Ver estado:

uso cuando se necesita para almacenar pequeñas cantidades de información de una página que va a publicar de nuevo a sí mismo. El uso de la propiedad ViewState proporciona funcionalidad con seguridad básica.

estado de control:

uso cuando se necesita para almacenar pequeñas cantidades de información de estado para un control entre ida y vuelta al servidor.

campos ocultos:

uso cuando se necesita para almacenar pequeñas cantidades de información de una página que va a publicar de nuevo a sí mismo oa otra página, y cuando la seguridad no es un problema.

Puede usar un campo oculto solo en las páginas que se envían al servidor.

Cookies:

su uso cuando se necesita para almacenar pequeñas cantidades de información sobre el cliente y la seguridad no es un problema.

cadena de consulta:

Se utiliza cuando se va a transferir pequeñas cantidades de información de una página a otra y la seguridad no es un problema.

Puede utilizar cadenas de consulta solo si está solicitando la misma página u otra página a través de un enlace.

las opciones de gestión de servidores secundarios

estado de aplicación

uso cuando se está almacenando rara vez cambian de información global y que es utilizado por muchos usuarios, y la seguridad no es un problema. No almacene grandes cantidades de información en el estado de la aplicación.

estado de sesión

uso cuando se está almacenando la información de corta duración que es específica para una sesión ya la seguridad individual es un problema. No almacene grandes cantidades de información en estado de sesión. Tenga en cuenta que se creará y mantendrá un objeto de estado de sesión durante toda la sesión de su aplicación. En las aplicaciones que alojan a muchos usuarios, esto puede ocupar importantes recursos del servidor y afectar la escalabilidad.

propiedades del perfil

su uso cuando se está almacenando información específica del usuario que necesita ser mantenido después de la sesión del usuario ha caducado y necesita ser recuperado de nuevo en visitas posteriores a su aplicación.

soporte de base de datos

Se utiliza cuando se va a almacenar grandes cantidades de información, la gestión de transacciones, o la información debe sobrevivir aplicación y de sesión se reinicia. La minería de datos es una preocupación y la seguridad es un problema.

Answer 2

Hay una gran cantidad de factores que pueden influir en esto, así que no voy a comentar sobre todos ellos. Pero aquí hay algunas sugerencias:

• ViewState - Esto es útil cuando se va a publicar de nuevo a la misma página con frecuencia (algo que está prácticamente obligado a hacer por ASP.NET Webforms). Lo útil que es exactamente cambia según el tipo de aplicación que esté creando. Para sitios de internet públicos, debe usarse con moderación. Es posible que desee apagarlo por defecto. Para sitios de intranet locales, es una gran herramienta — especialmente para las páginas de formularios web más pesados.

• Query String - Use esto para almacenar el estado que necesita para permitir que el usuario marque una página o proceso y vuelva a utilizarlo mucho más tarde. Incluso entonces, es posible que desee mantenerlo como un tipo de hash que puede usar como clave en una búsqueda de base de datos para evitar una url realmente grande (aunque los hashes tienen sus propios problemas). Además, a muchos usuarios les gusta jugar con su cadena de consulta directamente, por lo que puede ser peligroso poner demasiado aquí. Es fácil exponer accidentalmente datos a usuarios que no deberían verlo de esta manera.

• Application State - Recuerde que esto es compartido por todos los usuarios, por lo tanto, úselo apropiadamente. Cosas como conteos de visitas pueden ir aquí.

• Cookies - No utilice cookies para almacenar las credenciales del usuario. Simplemente son archivos de texto sin cifrar. Use cookies para almacenar una clave en la sesión (incluso aquí puede y debe usar ahora sesiones sin cookies) y configuraciones de personalización simples que serán específicas para ese usuario y navegador. Por ejemplo, el tamaño de mi monitor en el trabajo es diferente al de mi casa, por lo que es agradable colocar las configuraciones de tamaño/diseño en una cookie porque las configuraciones se adhieren a cada computadora, pero no va a comprometer mi seguridad si alguien más lee eso información.

Ahora quiero destacar este concepto desde la sección de "cadena de consulta":

es posible que desee mantenerla baja a algún tipo de hash que se puede utilizar como una llave en una base de datos de búsqueda

Una vez más, los hashes tienen sus propios problemas, pero quiero señalar que varios artículos en mi lista de conversación (incluyendo la cadena de consulta) sobre la carga de datos desde el navegador web del cliente al servidor web: ViewState, cadena de consulta , Cookie y publicación cruzada. Desea minimizar los datos que mueve de cliente a servidor. Este concepto se aplica a todos ellos, y por varias razones:

1. datos Tirando desde el cliente es lenta para los sitios públicos de Internet. Incluso las conexiones de banda ancha generalmente paralizan el ancho de banda disponible para cargar.512Kpbs (sigue siendo una tasa de carga de banda ancha típica en muchas áreas) es nada en comparación con la conexión Gigabit Ethernet (o más rápida) que probablemente se encuentre entre su base de datos y su servidor web. Por mucho que piense que una consulta de base de datos es lenta (y lo es), es probable que sea mucho mejor que esperar a que lleguen los mismos datos del cliente.
2. Mantener los datos en el servidor es más económico, porque no paga el ancho de banda requerido para enviarlo al cliente o desde él, y el ancho de banda a menudo cuesta tanto o más que el hardware de su servidor.
3. Es más seguro, porque si se hace bien incluso cuando la computadora o la conexión de un cliente se ve comprometida, todo lo que el hacker tiene acceso inicialmente es una clave hash que probablemente expira en el momento en que puede descifrarla. Por supuesto, si lo hace mal, puede usar esa clave directamente de inmediato, por lo que todavía debe tener cuidado.

Así que para la mayoría de las cosas, lo que recomiendo es comenzar manteniendo una clave de base de datos en la sesión y luego tener código para extraer fácilmente lo que necesita de una base de datos basada en esa clave. A medida que experimenta cuellos de botella, perfil para averiguar dónde están y comenzar a almacenar en caché esas páginas o controles, o mantener ese resultado de datos/consulta en la sesión directamente.

Answer 3

No estoy seguro si se refiere al objeto Caché por estado de la aplicación.

El objeto Caché es una forma excelente de administrar el estado general de la aplicación, p. para registrar el acceso a fuentes y recuentos en su sitio web (para evitar ataques DDOS, por ejemplo).

Answer 4

(3) de cadena de consulta (4) el estado de sesión (5) Estado de aplicación (6) Galletas

1. Viewstate

• Aviso: uso como poco como sea posible . Buen punto es siempre tener cada estado accesible por una url, si es posible.
  • F.e. La megafonía debe usar la URL (así que /url/?p=2 en lugar de almacenar la página en Viewstate)
• Se usa para persistir el estado de control entre ciclos de página.
  • F.e. Almacene el elemento seleccionado en una casilla de verificación, para que pueda determinar si ha cambiado.

2. Cruz página de publicación

no. Vea el descargo de responsabilidad para viewstate. Use la URL para esto o almacene los datos en una sesión/cookie/perfil si se deben mantener un montón de propiedades.

La principal desventaja de CPP es que el usuario no puede usar los botones 'Atrás' y 'Adelante' en su navegador web. Cuando un usuario hace clic en el botón Atrás, quiere deshacer todo en esa página y reintentar el último. Al usar CPP para hacer clic en ellos a través de un asistente; este comportamiento no es posible sin una gran cantidad de '¿Estás seguro de que deseas volver a enviar blablablabl'?

3.Query String

Use mucho. Todos los estados visibles que una página puede alcanzar deben ser accesibles por URL. Las personas con lectores de pantalla se lo agradecerán. Y al usar la cadena de consulta no hay necesidad de usar soluciones solo de JavaScript.

/url/?page=2 // when doing paging, don't use postback for this 
/url/?tab=advanced-search // when having tabs on top of your page 

etc.

4. El estado de sesión

Uso esto para objetos vida corta, que sólo tiene sentido este tiempo el usuario visita su sitio. Por ejemplo:

• ¿Qué paso de una cierta asistente se alcanzó
• Páginas de un usuario había visitado antes
• Los objetos pequeños que desea poner en la memoria caché, pero que están obligados por el usuario

no utilice sesiones sino perfiles para cosas como:

• Preferencias
• Idioma seleccionado

Porque esas cosas también tienen sentido la próxima vez que el usuario visite su sitio.

5. Estado de aplicación

Nunca. Use ASP.NET cache, o memcached, o cualquier marco de caché para esto.

6. Las cookies

ID de sesión, ID de perfil para los usuarios autenticados; preferencias del usuario para usuarios anónimos (todo lo que figura en la segunda lista en 4.).