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