ASP.NET Maestros: ¿Cuáles son las ventajas / desventajas de usar variables de sesión?

Mi experiencia ha sido que la sesión es un buen medio para administrar el estado cuando se usa apropiadamente. Sin embargo, muchas veces se usa mal, causando el sentimiento de "nunca uses la sesión" compartido por muchos desarrolladores.

Yo y muchos otros desarrolladores nos hemos encontrado con importantes problemas de rendimiento cuando hemos utilizado erróneamente la sesión para almacenar grandes cantidades de datos de una base de datos, con el fin de "ahorrar un viaje."Esto es malo. Almacenar 2000 registros de usuario por sesión traerá el servidor web a su rodillas cuando más de un par de usuarios utilizan la aplicación. La sesión no debe usarse como caché de base de datos.

Almacenar un entero, sin embargo, por sesión es perfectamente aceptable. Pequeñas cantidades de datos que representan cómo el usuario actual está usando su aplicación (piense en el carrito de compras) es un buen uso del estado de la sesión.

Para mí, realmente se trata de administrar el estado. Si se hace correctamente, la sesión puede ser una de las muchas buenas maneras de administrar el estado. Debe decidirse en el comenzando sobre cómo administrar el estado. La mayoría de las veces, nos hemos encontrado con problemas cuando alguien decide simplemente "lanzar algo en la sesión".

Encontré este artículo es realmente útil cuando se usan modos fuera de proceso, y contiene algunos consejos que nunca habría pensado por mi cuenta. Por ejemplo, en lugar de marcar una clase como serializable, almacenar sus miembros de tipo de datos primitivos en variables de sesión separadas y luego recrear el objeto puede mejorar rendimiento.

En primer lugar, su colega está implementando su propio sistema de administración de sesiones respaldado por BD, no veo qué ventaja tiene esto sobre el uso de estado de sesión incorporado almacenado en una base de datos (MS SQL es el predeterminado, no hay razón para no usar Oracle en su lugar).

¿Es su solución mejor que la integrada? Probable. Es mucho más trabajo para ti para empezar. Aquí hay una simple ilustración de por qué. Digamos que utiliza cookies para almacenar su ID, ¿cómo hacer frente a un usuario que desactiva las cookies? Si vosotros habéis utilizado ASP.Net no hay problema, ya que volverá a usar la cadena de consulta. Con la idea de tus colegas tienes que rodar la tuya.

Existe una pregunta muy válida en cuanto a si debe tener el estado de sesión en absoluto. Si puede diseñar su aplicación para que no necesite ningún estado de sesión en absoluto, tendrá un escalado y pruebas de tiempo mucho más fáciles. Obviamente, puede tener estado de la aplicación que necesita vivir más allá de una sesión de todos modos (caso simple beign nombres de usuario y contraseñas), pero usted tiene que almacenar estos datos de todos modos, independientemente de si usted tiene el estado de la sesión.

La implementación de MS del Estado de sesión no es mala en sí misma... es la forma en que algunos desarrolladores lo utilizan. Como se mencionó anteriormente, el uso del proveedor de estado de sesión integrado significa que no tiene que reinventar los problemas de seguridad, envejecimiento y concurrencia. Simplemente no empieces a atascar mucha basura en la sesión porque eres demasiado perezoso para encontrar una mejor manera de administrar las transiciones de estado y de página. La sesión no escala muy bien... si cada usuario en su sitio stuffs un montón de objetos en el sesión, y esos objetos ocupan un poco de la memoria finita disponible para su aplicación, se encontrará con problemas más pronto que tarde a medida que su aplicación crezca en popularidad. Use la sesión de la manera para la que fue diseñada: un token para representar que un usuario todavía está "usando" su sitio. Cuando empiezas a aventurarte más allá de eso, ya sea por ignorancia o pereza, estás obligado a quemarte.

Debe ser juicioso en su uso de la sesión, ya que las solicitudes múltiples al mismo objeto de sesión generalmente se pondrán en cola: consulte "Solicitudes simultáneas y estado de la sesión" http://msdn.microsoft.com/en-us/library/ms178581.aspx .

Tenga en cuenta que puede establecer EnableSessionState a ReadOnly para permitir el acceso de lectura concurrente al estado de la sesión.

Esta cola es algo bueno, ya que significa que los desarrolladores pueden usar la sesión sin preocuparse por la sincronización.

No lo haría de acuerdo con la recomendación de su colega de "nunca" usar Sesión y ciertamente no consideraría rodar la mía.

¿Hay algún problema de seguridad con esto?

Si lanzas el tuyo tendrás que manejar la Fijación de Sesión y los ataques de Secuestro, mientras que usando la Sesión incorporada creo que se manejan por ti (pero podría estar equivocado).

La sesión hecha en casa como usted ha descrito no está haciendo nada diferente "SQL" estado de sesiones.Net y en mi experiencia no creo que la sesión degrada su rendimiento en todos modos. la construcción de su propio administrador de sesiones requerirá poner en varias otras tareas de plomería a lo largo de - seguridad, enjuagarlo, etc.

La ventaja con las sesiones integradas es su fácil de usar con toda esta plomería ya se ha cuidado. con el modo" SQL " puede conservar los datos de la sesión en la base de datos lo que le permite ejecutar su aplicación en granjas web sin ningún problema.

Diseñamos una aplicación de comercio electrónico b2b para la empresa fortune 57 que procesa más de 100 mil transacciones al día y utiliza sesiones [modo SQL] bastante extensivamente sin ningún problema en absoluto.

Corrígeme si me equivoco:

La principal ventaja de almacenar el estado de la sesión en una base de datos, por ejemplo, SQL Server, es que no está consumiendo recursos de memoria, sino que los almacena en el disco en una base de datos.

La desventaja es que toma un golpe de IO para recuperar esta información de la base de datos cada vez que la necesita (o tal vez SQL Sever incluso hace algún almacenamiento en caché mágico de los datos para usted basado en consultas ejecutadas recientemente?)

En cualquier caso, este es el precio de un IO para recuperar la sesión la información de una base de datos por viaje al servidor web parece una estrategia más segura para los sitios que encuentran mucho tráfico.