|
Migración a ASP .NET: consideraciones clave
Administración de estado
Si su aplicación emplea los objetos intrínsecos Session
o Application para almacenar la información de estado,
podrá seguir usándolos en ASP .NET sin ningún problema. Además
contará con varias opciones adicionales para la ubicación
donde almacene el estado.
Opciones de administración de estado
En ASP .NET, existen opciones adicionales para el modelo de
almacenamiento de estado que permitirán por fin ir más allá de
un solo servidor Web y admitirán la administración de estado
en toda una red.
Estas opciones se pueden configurar en la sección
<sessionState> de su archivo
web.config del siguiente modo:
<sessionState
mode="Inproc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false"
timeout="20"
/>
El atributo de modo especifica la ubicación donde desea
guardar la información de estado. Las opciones disponibles son
Inproc, StateServer, SqlServer y Off.
Tabla 4. Información sobre el almacenamiento del estado
de la sesión
| Opción |
Descripción |
| Inproc |
El estado de la sesión se
guarda en este servidor (estilo ASP). |
| StateServer |
El estado de la sesión se
guarda en un proceso de servicio de estado ubicado
localmente o en algún lugar remoto. |
| SqlServer |
El estado de la sesión se
almacena en una base de datos SQL Server. |
| Off |
El estado de la sesión se
inhabilita. |
StateConnectionString y sqlConnectionString
también han de tenerse en cuenta si utiliza alguna de estas
opciones. Sólo se puede utilizar una opción de almacenamiento
por aplicación.
Almacenamiento de componentes COM
Algo que hay que tener en cuenta si depende de referencias
de almacenamiento a sus anteriores componentes COM en el
objeto Session o Application es que los nuevos
mecanismos de almacenamiento (StateServer o
SqlServer) no se pueden utilizar dentro de la aplicación.
En su lugar, deberá emplear Inproc. Esto se debe, en
parte, a la necesidad de que un objeto se pueda serializar en
términos .NET, algo que obviamente no pueden hacer los
componentes COM. Por otra parte, los nuevos componentes
administrados que cree pueden realizar esta tarea fácilmente
y, por consiguiente, pueden aprovechar los nuevos modelos de
almacenamiento del estado.
Rendimiento
En lo que respecta al rendimiento, todo tiene un precio,
por supuesto. Se puede asumir sin riesgo a equivocarse que, en
la mayoría de los casos, Inproc continuará siendo el
más efectivo, seguido de StateServer y SqlServer.
Tendrá que probarlos con su aplicación para asegurarse de que
la opción seleccionada rinde del modo esperado.
Uso compartido del estado entre ASP y ASP .NET
Otro punto que hay que considerar es que, a pesar de que su
aplicación puede albergar tanto páginas ASP como ASP .NET, no
se pueden compartir las variables de estado almacenadas en los
objetos intrínsecos Session o Application. Esta
información se debe duplicar en ambos sistemas o utilizar una
solución personalizada hasta que la migración de la aplicación
se haya completado. Lo más importante es que si los objetos
Session y Application se han utilizado poco, no
debería haber motivos para preocuparse. Si, por el contrario,
estos objetos se han utilizado con frecuencia, será necesario
actuar con precaución y quizá haya que utilizar una solución
personalizada a corto plazo para compartir el estado.
LO ÚLTIMO
en tu Correo.
Suscríbete Gratis a NUESTRO BOLETÍN !!
Te Agradeceríamos nos informes si encuentras un
ENLACE
ROTO
|
Software
Gratis
