sábado, 3 de noviembre de 2012

ASP.NET - Recomendaciones para elegir la técnica de manejo de estado adecuada para nuestro site

El protocolo HTTP por defecto no admite estados lo que implica que el servidor web trata cada petición de un navegador como una petición independiente. Ciertos sitios web necesitan mantener persistencia entre las peticiones de un mismo cliente como una tienda on-line con cesta de la compra por poner un ejemplo.

Cuando iniciamos el diseño de un site ASP.NET en el que necesitamos mantener un estado entre las peticiones de un mismo cliente-servidor es recomendable analizar parámetros como el tipo de información que almacenaremos, confidencialidad, volumen y previsión del número de clientes simultáneos del site.

ASP.NET proporciona varias técnicas basadas en cliente y servidor para compartir información en forma de estado entre diferentes peticiones.

  • Si usamos controles de servidor ASP.NET mediante la propiedad ViewState de estos hacemos que la información viaje en cada petición oculta de modo que es sencillo recuperar valores entre 2 páginas. También se pueden usar otras técnicas cliente como Query String, Hidden Fields o Cookies. Estas técnicas que acabamos de mencionar se basan en cliente, implica que la información que necesitamos que sea persistente entre las peticiones viaja en cada petición oculta o se almacena en el navegador como es el caso de las cookies.
  • Por otro lado ASP.NET proporciona técnicas de control de estado basadas en servidor como Application State, Session State o Profile Properties que permiten al servidor almacenar información por lo que no es necesario que esta viaje en cada petición entre cliente y servidor. A la contra esta alternativa consume más recursos en el servidor web y si no se gestiona bien podría llegar a afectar al rendimiento del site.

La elección de la técnica adecuada dependerá del escenario que se nos plantee veamos algún ejemplo que nos ayudará a verlo más claro.

  • Un particular o pequeña compañía se plantea diseñar un site con visión comercial en el que no sabemos de inicio el número de usuarios que van a registrarse pero interesa que sean el máximo posible. El site dispone de un acceso privado que permite al usuario registrado realizar una gestión on-line en la que los datos persistentes entre páginas no serán estrictamente confidenciales y además no disponemos de servidor web propio y necesitamos hospedar el site con un tercero que ofrece servicios de hosting.

  • Una compañía con un número considerable de empleados y clientes se plantea diseñar un site que proporcione una serie de funcionalidades a sus usuarios. Por ejemplo interesa que los usuarios en función del tipo de perfil puedan realizar unas acciones determinadas de negocio que enlacen con otras aplicaciones. Supongamos que el volumen de información que necesitamos mantener a modo de sesión es elevado y además la información que se manipula es sensible y no conviene que sea accesible a usuarios malintencionados. La compañía dispone en este caso de una granja de servidores web propia alojada en sus sistemas.

En el primer ejemplo, es muy posible que no tengamos control sobre los recursos de máquina que tenemos asignados en el servidor y probablemente tampoco tengamos control total sobre la configuración del site. Además no sabemos el número de usuarios que podrían llegar a usar el site simultáneamente. En este caso sería recomendable no usar técnicas basadas en servidor en nuestro código porque por defecto ASP.NET almacenará en RAM del servidor web la información y esto podría originar un problema. Con técnicas basadas en cliente nos aseguraremos que la persistencia de la información se almacena en cliente o hacemos que viaje en cada petición lo que implica que el servidor no necesita almacenar información sobre los clientes que están conectados y no corremos el riesgo de desbordar los recursos de máquina.

En el segundo ejemplo nos interesaría decantarnos por una técnica basada en servidor porque la información que necesitamos hacer persistente contiene datos sobre roles, accesos, cuentas u otro tipo de información confidencial y hay que evitar que viajen entre cliente y servidor en cada petición para no comprometer la seguridad del site. Otra ventaja de este diseño es que la comunicación entre cliente y servidor será más ligera. Es posible que la configuración por defecto sea suficiente dado que no tengamos un número muy elevado de usuarios concurrenetes pero si por lo que sea la situación cambia, como tenemos acceso al servidor, podríamos modificar el comportamiento por defecto de un site ASP.NET con el fin de evitar cargar la RAM del servidor almacenando el estado en una base de datos o delegando la gestión a un servicio o equipo remoto... en definitiva podríamos diseñar arquitecturas un poco más complejas, si se da el caso, para garantizar el buen rendimiento y seguridad del site.

Hasta aquí el post de esta semana, en la sección ASP.NET podréis encontrar artículos relacionados que os podrían interesar. También podéis seguir areaTIC en las redes sociales y RSS!


No hay comentarios:

Publicar un comentario en la entrada