Formularios web ASP.NET

ASP.NET Web Forms es un marco de trabajo para aplicaciones web y uno de los varios modelos de programación compatibles con la tecnología Microsoft ASP.NET . Las aplicaciones Web Forms se pueden escribir en cualquier lenguaje de programación que admita Common Language Runtime , como C# o Visual Basic . Los principales componentes básicos de las páginas Web Forms son los controles de servidor , que son componentes reutilizables responsables de representar el marcado HTML y responder a los eventos. ^[1] Se utiliza una técnica denominada estado de vista para conservar el estado de los controles de servidor entre solicitudes HTTP normalmente sin estado . ^[2]

Web Forms se incluyó en la versión original de .NET Framework 1.0 en 2002 (consulte el historial de versiones de .NET Framework y el historial de versiones de ASP.NET ), como el primer modelo de programación disponible en ASP.NET. A diferencia de los componentes ASP.NET más nuevos, Web Forms no es compatible con ASP.NET Core . ^[3]

Las páginas web ASP.NET, conocidas oficialmente como Web Forms, ^[4] fueron los principales bloques de construcción para el desarrollo de aplicaciones en ASP.NET antes de la introducción de MVC. ^[5] Existen dos metodologías básicas para Web Forms: un formato de aplicación web y un formato de sitio web. ^[6] Las aplicaciones web deben compilarse antes de la implementación, mientras que los sitios web permiten al usuario copiar los archivos directamente al servidor sin compilación previa. Los formularios web están contenidos en archivos con una extensión ".aspx"; estos archivos generalmente contienen marcado HTML estático ( X ) o marcado de componente. El marcado de componente puede incluir controles web del lado del servidor y controles de usuario que se han definido en el marco o la página web. Por ejemplo, un componente de cuadro de texto se puede definir en una página como , que se representa en un cuadro de entrada html. Además, el código dinámico, que se ejecuta en el servidor, se puede colocar en una página dentro de un bloque , que es similar a otras tecnologías de desarrollo web como PHP , JSP y ASP . Con ASP.NET Framework 2.0 , Microsoft introdujo un nuevo modelo de código subyacente que permite que el texto estático permanezca en la página .aspx mientras que el código dinámico va a un archivo .aspx.vb o .aspx.cs o .aspx.fs (según el lenguaje de programación utilizado). ^[7]<asp:textbox id='myid' runat='server'><% -- dynamic code -- %>

Microsoft recomienda trabajar con código de programa dinámico mediante el modelo de código subyacente, que coloca este código en un archivo independiente o en una etiqueta de script especialmente designada. Los archivos de código subyacente suelen tener nombres como " MyPage.aspx.cs" o " MyPage.aspx.vb" , mientras que el archivo de página es MyPage.aspx (el mismo nombre de archivo que el archivo de página (ASPX), pero con la extensión final que indica el idioma de la página). Esta práctica es automática en Visual Studio y otros IDE , aunque el usuario puede cambiar el nombre de la página de código subyacente. Además, en el formato de aplicación web, pagename.aspx.cs es una clase parcial que está vinculada al archivo pagename.designer.cs. El archivo de diseñador es un archivo que se genera automáticamente a partir de la página ASPX y permite al programador hacer referencia a los componentes en la página ASPX desde la página de código subyacente sin tener que declararlos manualmente, como era necesario en las versiones de ASP.NET anteriores a la versión 2. ^[8] Al utilizar este estilo de programación, el desarrollador escribe código para responder a diferentes eventos, como la carga de la página o el clic en un control, en lugar de un recorrido procedimental del documento.

El modelo de código subyacente de ASP.NET marca una diferencia con respecto a ASP clásico, ya que alienta a los desarrolladores a crear aplicaciones teniendo en mente la separación de la presentación y el contenido . En teoría, esto permitiría a un diseñador web, por ejemplo, centrarse en el marcado de diseño con menos posibilidades de alterar el código de programación que lo impulsa. Esto es similar a la separación del controlador de la vista en los marcos modelo-vista-controlador (MVC).

Una directiva es una instrucción especial sobre cómo ASP.NET debe procesar la página. ^[9] La directiva más común es <%@ Page %>, que puede especificar muchos atributos utilizados por el analizador y compilador de páginas ASP.NET.

Los controles de usuario son encapsulaciones de secciones de páginas que se registran y utilizan como controles en ASP.NET.

Los programadores también pueden crear controles personalizados para aplicaciones ASP.NET. A diferencia de los controles de usuario, estos controles no tienen un archivo de marcado ASCX, sino que todo su código se compila en un archivo de biblioteca de vínculos dinámicos (DLL) . Estos controles personalizados se pueden utilizar en varias aplicaciones web y proyectos de Visual Studio 2013 .

.NET utiliza una técnica de representación de "composiciones visitadas". Durante la compilación, el archivo de plantilla (.aspx) se compila en código de inicialización que crea un árbol de control (la composición) que representa la plantilla original. El texto literal va en instancias de la clase de control Literal y los controles de servidor se representan mediante instancias de una clase de control específica. El código de inicialización se combina con el código escrito por el usuario (normalmente mediante el ensamblaje de varias clases parciales) y da como resultado una clase específica para la página. La página funciona como la raíz del árbol de control.

Las solicitudes reales de la página se procesan mediante una serie de pasos. En primer lugar, durante los pasos de inicialización, se crea una instancia de la clase de página y se ejecuta el código de inicialización. Esto produce el árbol de control inicial, que ahora normalmente se manipula mediante los métodos de la página en los pasos siguientes. Como cada nodo del árbol es un control representado como una instancia de una clase, el código puede cambiar la estructura del árbol, así como manipular las propiedades/métodos de los nodos individuales. Por último, durante el paso de representación, se utiliza un visitante para visitar cada nodo del árbol, y se le pide a cada nodo que se represente a sí mismo utilizando los métodos del visitante. La salida HTML resultante se envía al cliente.

Una vez procesada la solicitud, se descarta la instancia de la clase de página y, con ella, todo el árbol de control. Esto es una fuente de confusión entre los programadores novatos de ASP.NET que dependen de los miembros de la instancia de clase que se pierden con cada ciclo de solicitud/respuesta de página.

Las aplicaciones ASP.NET están alojadas en un servidor web y se accede a ellas mediante el protocolo HTTP sin estado . Por tanto, si una aplicación utiliza interacción con estado, tiene que implementar la gestión de estado por sí misma. ASP.NET ofrece varias funciones para la gestión de estado. Conceptualmente, Microsoft trata el "estado" como el estado de la GUI . Pueden surgir problemas si una aplicación debe realizar un seguimiento del "estado de los datos"; por ejemplo, una máquina de estados finitos que puede estar en un estado transitorio entre solicitudes ( evaluación diferida ) o que tarda mucho tiempo en inicializarse. La gestión de estado en páginas ASP.NET con autenticación puede dificultar o imposibilitar el raspado web .

El estado de la aplicación se mantiene mediante una colección de variables compartidas definidas por el usuario. Estas se establecen e inicializan cuando Application_OnStartse activa el evento al cargar la primera instancia de la aplicación y están disponibles hasta que finaliza la última instancia. Se accede a las variables de estado de la aplicación mediante la Applicationscolección, que proporciona un contenedor para el estado de la aplicación. Las variables de estado de la aplicación se identifican por nombre. ^[10] La aplicación es gestión de estado.

El estado de la sesión del lado del servidor se mantiene mediante una colección de variables de sesión definidas por el usuario que son persistentes durante una sesión de usuario. Estas variables, a las que se accede mediante la Sessioncolección, son únicas para cada instancia de sesión. Las variables se pueden configurar para que se destruyan automáticamente después de un tiempo definido de inactividad, incluso si la sesión no finaliza. La sesión del usuario del lado del cliente se mantiene mediante una cookie o codificando el ID de sesión en la propia URL. ^[10]

ASP.NET admite tres modos de persistencia para las variables de sesión del lado del servidor: ^[10]

Modo en proceso

Las variables de sesión se mantienen dentro del proceso ASP.NET . Esta es la forma más rápida; sin embargo, en este modo las variables se destruyen cuando el proceso ASP.NET se recicla o se cierra.

Modo de servidor de estado

ASP.NET ejecuta un servicio de Windows independiente que mantiene las variables de estado. Debido a que la administración de estado se realiza fuera del proceso ASP.NET y debido a que el motor ASP.NET accede a los datos mediante .NET Remoting, ASPState es más lento que In-Process. Este modo permite equilibrar la carga de una aplicación ASP.NET y escalarla entre varios servidores. Debido a que el servicio de administración de estado se ejecuta de forma independiente de ASP.NET, las variables de sesión pueden persistir tras el cierre del proceso ASP.NET. Sin embargo, dado que el servidor de estado de sesión se ejecuta como una instancia, sigue siendo un punto de falla para el estado de sesión. El servicio de estado de sesión no se puede equilibrar en cuanto a la carga y existen restricciones sobre los tipos que se pueden almacenar en una variable de sesión.

Modo SQL Server

Las variables de estado se almacenan en una base de datos , lo que permite que las variables de sesión se mantengan en el tiempo tras el cierre de un proceso ASP.NET. La principal ventaja de este modo es que permite que la aplicación equilibre la carga en un clúster de servidores, compartiendo sesiones entre servidores. Este es el método más lento de gestión del estado de sesión en ASP.NET.

El estado de sesión de ASP.NET permite almacenar y recuperar valores para un usuario mientras navega por páginas ASP.NET en una aplicación web. HTTP es un protocolo sin estado. Esto significa que un servidor web trata cada solicitud HTTP de una página como una solicitud independiente. El servidor no conserva ningún conocimiento de los valores de las variables que se utilizaron durante solicitudes anteriores. El estado de sesión de ASP.NET identifica las solicitudes del mismo explorador durante un período de tiempo limitado como una sesión y proporciona una forma de conservar los valores de las variables durante la duración de esa sesión. De forma predeterminada, el estado de sesión de ASP.NET está habilitado para todas las aplicaciones ASP.NET.

Las alternativas al estado de la sesión incluyen las siguientes:

• Estado de la aplicación, que almacena variables a las que pueden acceder todos los usuarios de una aplicación ASP.NET.
• Propiedades de perfil, que conservan los valores del usuario en un almacén de datos sin hacerlos caducar.
• Almacenamiento en caché ASP.NET, que almacena valores en la memoria que está disponible para todas las aplicaciones ASP.NET.
• Estado de la vista, que conserva los valores en una página.
• Galletas.
• La cadena de consulta y los campos de un formulario HTML que están disponibles mediante una solicitud HTTP.

El estado de vista se refiere al mecanismo de administración de estado a nivel de página, utilizado por las páginas HTML emitidas por las aplicaciones ASP.NET para mantener el estado de los controles y widgets de formularios web . El estado de los controles se codifica y se envía al servidor en cada envío de formulario en un campo oculto conocido como __VIEWSTATE. El servidor envía de vuelta la variable para que, cuando se vuelva a renderizar la página, los controles se rendericen en su último estado. En el lado del servidor, la aplicación puede cambiar el estado de vista, si el procesamiento requiere un cambio de estado de algún control. Los estados de los controles individuales se decodifican en el servidor y están disponibles para su uso en páginas ASP.NET mediante la ViewStatecolección. ^[11]

El uso principal de esto es preservar la información del formulario en los postbacks. El estado de vista está activado de forma predeterminada y normalmente serializa los datos en cada control de la página, independientemente de si se utiliza realmente durante un postback. Sin embargo, este comportamiento se puede (y se debe) modificar, ya que el estado de vista se puede deshabilitar por control, por página o en todo el servidor.

Los desarrolladores deben tener cuidado al almacenar información confidencial o privada en el estado de vista de una página o control, ya que la cadena Base64 que contiene los datos del estado de vista se puede deserializar fácilmente. De manera predeterminada, el estado de vista no cifra el __VIEWSTATEvalor. El cifrado se puede habilitar en todo el servidor (y en cada servidor en particular), lo que permite mantener un cierto nivel de seguridad. ^[12]

ASP.NET ofrece un objeto "Caché" que se comparte en toda la aplicación y que también se puede utilizar para almacenar varios objetos. El objeto "Caché" conserva los datos solo durante un período de tiempo específico.

Otros medios de gestión de estado compatibles con ASP.NET son las cookies , el almacenamiento en caché y la cadena de consulta .

Cuando se lanzó por primera vez, ASP.NET carecía de un motor de plantillas . Debido a que .NET Framework está orientado a objetos y permite la herencia , muchos desarrolladores definían una nueva clase base que hereda de " System.Web.UI.Page", escribían allí métodos que renderizaban HTML y luego hacían que las páginas de su aplicación heredaran de esta nueva clase. Si bien esto permite reutilizar elementos comunes en un sitio, agrega complejidad y mezcla el código fuente con el marcado . Además, este método solo se puede probar visualmente ejecutando la aplicación, no mientras se la diseña. Otros desarrolladores han utilizado archivos de inclusión y otros trucos para evitar tener que implementar la misma navegación y otros elementos en cada página.

ASP.NET 2.0 introdujo el concepto de páginas maestras , que permiten el desarrollo de páginas basadas en plantillas . Una aplicación web puede tener una o más páginas maestras, que, a partir de ASP.NET 2.0, se pueden anidar. ^[13] Las plantillas maestras tienen controles de marcador de posición, llamados ContentPlaceHolders, para indicar dónde va el contenido dinámico, así como HTML y JavaScript compartidos entre las páginas secundarias.

Las páginas secundarias utilizan esos controles ContentPlaceHolder, que deben asignarse al marcador de posición de la página maestra que la página de contenido está rellenando. El resto de la página se define mediante las partes compartidas de la página maestra, de forma muy similar a una combinación de correspondencia en un procesador de textos . Todos los controles de marcado y servidor de la página de contenido deben colocarse dentro del control ContentPlaceHolder.

Cuando se realiza una solicitud de una página de contenido, ASP.NET fusiona la salida de la página de contenido con la salida de la página maestra y envía la salida al usuario.

La página maestra sigue siendo completamente accesible para la página de contenido. Esto significa que la página de contenido aún puede manipular encabezados, cambiar títulos, configurar el almacenamiento en caché, etc. Si la página maestra expone propiedades o métodos públicos (por ejemplo, para configurar avisos de derechos de autor), la página de contenido también puede usarlos.

Otras extensiones de archivo asociadas con diferentes versiones de ASP.NET incluyen:

En general, la estructura de directorios de ASP.NET puede determinarse según las preferencias del desarrollador. Aparte de unos pocos nombres de directorios reservados, el sitio puede abarcar cualquier cantidad de directorios. La estructura normalmente se refleja directamente en las URL. Aunque ASP.NET proporciona medios para interceptar la solicitud en cualquier momento durante el procesamiento, el desarrollador no está obligado a canalizar las solicitudes a través de una aplicación central o un controlador frontal.

Los nombres de directorio especiales (a partir de ASP.NET 2.0) son: ^[16]

Código de la aplicación

Este es el directorio de "código sin procesar". El servidor ASP.NET compila automáticamente los archivos (y subdirectorios) de esta carpeta en un ensamblado accesible en el código de cada página del sitio. App_Code se utiliza normalmente para el código de abstracción de acceso a datos, el código de modelo y el código comercial. También se incluyen en este directorio todos los controladores y módulos http específicos del sitio y la implementación del servicio web. Como alternativa al uso de App_Code, el desarrollador puede optar por proporcionar un ensamblado independiente con código precompilado.

Datos de la aplicación

El directorio App_Data de ASP.NET es el directorio predeterminado para cualquier base de datos utilizada por el sitio web ASP.NET. Estas bases de datos pueden incluir archivos de Access (mdb) o de SQL Server (mdf). App_Data es el único directorio con acceso de escritura habilitado para la aplicación web ASP.NET.: ^[17]

Recursos globales de la aplicación

Contiene archivos resx con recursos localizados disponibles para cada página del sitio. Aquí es donde el desarrollador de ASP.NET normalmente almacena mensajes localizados, etc., utilizados en más de una página.

Recursos locales de la aplicación

Por ejemplo, un archivo llamado CheckOut.aspx.fr-FR.resx contiene recursos localizados para la versión en francés de la página CheckOut.aspx. Cuando la cultura de la interfaz de usuario está configurada en francés, ASP.NET busca y utiliza automáticamente este archivo para la localización.

Aplicación fuera de línea.htm

Un archivo (no un directorio) que deshabilita la aplicación devolviendo el contenido del archivo para cualquier solicitud de la aplicación.

Temas de la aplicación

Agrega una carpeta que contiene archivos relacionados con los temas, lo cual es una nueva característica de ASP.NET que ayuda a garantizar una apariencia consistente en todo el sitio web y facilita el cambio de la apariencia del sitio web cuando sea necesario.

Referencias de la aplicación web

Contiene archivos de descubrimiento y archivos WSDL para referencias a servicios web que se consumirán en el sitio.

Papelera

Contiene código compilado ( archivos .dll ) para controles, componentes u otro código al que desee hacer referencia en su aplicación. Todas las clases representadas por código en la carpeta Bin se referencian automáticamente en su aplicación.

ASP.NET busca obtener ventajas en el rendimiento sobre otras tecnologías basadas en scripts (incluido ASP clásico) compilando el código del lado del servidor la primera vez que se utiliza en uno o más archivos DLL en el servidor web . Estos archivos DLL o ensamblajes contienen Microsoft Intermediate Language (MSIL) para ejecutarse dentro del Common Language Runtime ; esto proporciona un aumento del rendimiento sobre los lenguajes de script puros y es similar al enfoque utilizado por Python y no muy diferente a JavaServer Pages . ^[18] Esta compilación ocurre automáticamente la primera vez que se solicita una página (lo que significa que el desarrollador no necesita realizar un paso de compilación separado para las páginas).

Esta característica proporciona la facilidad de desarrollo que ofrecen los lenguajes de programación con las ventajas de rendimiento de un binario compilado. Sin embargo, la compilación puede provocar un retraso notable pero breve para el usuario cuando se solicita por primera vez la página recién editada desde el servidor web, pero no nuevamente a menos que la página solicitada se actualice más.

Los archivos ASPX y otros archivos de recursos se colocan en un host virtual en un servidor de Internet Information Services (u otros servidores ASP.NET compatibles; consulte Otras implementaciones, a continuación). La primera vez que un cliente solicita una página, .NET Framework analiza y compila los archivos en un ensamblado .NET y envía la respuesta; las solicitudes posteriores se atienden desde los archivos DLL. De forma predeterminada, ASP.NET compila todo el sitio en lotes de 1000 archivos tras la primera solicitud. Si el retraso en la compilación está causando problemas, se puede ajustar el tamaño del lote o la estrategia de compilación.

Los desarrolladores también pueden optar por precompilar sus archivos de "código subyacente" antes de la implementación, utilizando Microsoft Visual Studio, eliminando así la necesidad de una compilación en tiempo real en un entorno de producción. ^[19] Esto también elimina la necesidad de tener el código fuente en el servidor web. También admite la precompilación de texto.

ASP.NET WebForms simplifica la transición de los desarrolladores del desarrollo de aplicaciones de Windows al desarrollo web al ofrecer la posibilidad de crear páginas compuestas de controles similares a una interfaz de usuario de Windows . Un control web, como un botón o una etiqueta , funciona de forma muy similar a sus contrapartes de Windows: el código puede asignar sus propiedades y responder a sus eventos. Los controles saben cómo representarse a sí mismos: mientras que los controles de Windows se dibujan a sí mismos en la pantalla, los controles web producen segmentos de HTML y JavaScript que forman parte de la página resultante que se envía al navegador del usuario final.

ASP.NET WebForms alienta al programador a desarrollar aplicaciones utilizando un modelo de interfaz gráfica de usuario basado en eventos , en lugar de entornos de scripting web convencionales como ASP y PHP . El marco combina tecnologías existentes como JavaScript con componentes internos como " ViewState " para brindar un estado persistente (entre solicitudes) al entorno web inherentemente sin estado .

Otras diferencias respecto al ASP Clásico son:

• El código compilado significa que las aplicaciones se ejecutan más rápido con más errores de diseño atrapados en la etapa de desarrollo.
• Manejo de errores en tiempo de ejecución significativamente mejorado, haciendo uso del manejo de excepciones mediante bloques try-catch.
• Metáforas similares a las aplicaciones de Microsoft Windows, como controles y eventos.
• Un amplio conjunto de controles y bibliotecas de clases, así como controles definidos por el usuario, permiten la creación rápida de aplicaciones. La disposición de estos controles en una página es más sencilla porque la mayor parte se puede realizar visualmente en la mayoría de los editores.
• ASP.NET utiliza las capacidades multilenguaje de .NET Common Language Runtime , lo que permite codificar páginas web en VB.NET, C#, F#, Delphi.NET, etc.
• Capacidad de almacenar en caché toda la página o solo partes de ella para mejorar el rendimiento.
• Capacidad para utilizar el modelo de desarrollo de código subyacente para separar la lógica empresarial de la presentación.
• Capacidad de utilizar un verdadero diseño orientado a objetos para programar páginas y controles.
• Si una aplicación ASP.NET pierde memoria , el entorno de ejecución de ASP.NET descarga el AppDomain que aloja la aplicación con errores y vuelve a cargar la aplicación en un nuevo AppDomain.
• El estado de la sesión en ASP.NET se puede guardar en una base de datos de Microsoft SQL Server o en un proceso independiente que se ejecuta en la misma máquina que el servidor web o en una máquina diferente. De esa manera, los valores de la sesión no se pierden cuando se reinicia el servidor web o se recicla el proceso de trabajo de ASP.NET.
• Las versiones de ASP.NET anteriores a la 2.0 fueron criticadas por su falta de cumplimiento de los estándares. El HTML y el JavaScript generados que se enviaban al navegador del cliente no siempre se validaban con los estándares W3C / ECMA . Además, la función de detección de navegadores del marco de trabajo a veces identificaba incorrectamente a los navegadores web distintos del propio Internet Explorer de Microsoft como "de nivel inferior" y devolvía HTML/JavaScript a estos clientes con algunas de las funciones eliminadas, o a veces dañadas o rotas. Sin embargo, en la versión 2.0, todos los controles generan una salida válida en HTML 4.0, XHTML 1.0 (el valor predeterminado) o XHTML 1.1, según la configuración del sitio. La detección de navegadores web que cumplen con los estándares es más sólida y la compatibilidad con hojas de estilo en cascada es más amplia.
• Controles de servidor web: son controles introducidos por ASP.NET WebForms para proporcionar la interfaz de usuario para el formulario web. Estos controles son controles administrados por estado y son controles WYSIWYG .

• MacDonald, Mateo; Szpuszta, Mario (2005). Pro ASP.NET 2.0 en C# 2005 (1ª ed.). Presione. ISBN 978-1-59059-496-4.

• Documentación oficial
• Formularios web en www.asp.net
• Introducción a ASP.NET y formularios web (un documento de principios de 2001)