ASP.NET Web Forms es un marco de aplicación web y uno de varios modelos de programación compatibles con la tecnología Microsoft ASP.NET . Las aplicaciones de 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 de Web Forms son los controles del servidor , que son componentes reutilizables responsables de representar el marcado HTML y responder a los eventos. [1] Se utiliza una técnica llamada estado de vista para conservar el estado de los controles del 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, ASP.NET Core no admite Web Forms . [3]
Las páginas web ASP.NET, conocidas oficialmente como Web Forms, [4] eran los principales componentes básicos para el desarrollo de aplicaciones en ASP.NET antes de la introducción de MVC. [5] Hay dos metodologías básicas para los formularios web: un formato de aplicación web y un formato de sitio web. [6] Las aplicaciones web deben compilarse antes de su 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 extensión ".aspx"; Estos archivos normalmente contienen marcado HTML estático ( X ) o marcado de componente. El marcado del componente puede incluir controles web del lado del servidor y controles de usuario que se hayan definido en el marco o en 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 , lo cual 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 tratar el código de programa dinámico utilizando el modelo de código subyacente, que coloca este código en un archivo separado o en una etiqueta de secuencia de comandos especialmente designada. Los archivos de código subyacente normalmente tienen 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 la página idioma). 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 desde la página ASPX y permite al programador hacer referencia a 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] Cuando se utiliza este estilo de programación, el desarrollador escribe código para responder a diferentes eventos, como la página que se carga o un control en el que se hace clic, en lugar de un recorrido de procedimiento del documento.
El modelo de código subyacente de ASP.NET marca una desviación del ASP clásico en el sentido de que anima a los desarrolladores a crear aplicaciones teniendo en cuenta la separación de presentación y contenido . En teoría, esto permitiría a un diseñador web, por ejemplo, centrarse en el marcado de diseño con menos potencial 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 y todo su código está compilado en un archivo de biblioteca de vínculos dinámicos (DLL) . Estos controles personalizados se pueden utilizar en múltiples aplicaciones web y proyectos de Visual Studio 2013 .
.NET utiliza una técnica de representación de "compuestos visitados". Durante la compilación, el archivo de plantilla (.aspx) se compila en un código de inicialización que crea un árbol de control (el compuesto) que representa la plantilla original. El texto literal va a instancias de la clase de control Literal y los controles del servidor están representados por instancias de una clase de control específica. El código de inicialización se combina con código escrito por el usuario (generalmente mediante el ensamblaje de múltiples clases parciales) y da como resultado una clase específica para la página. La página también funciona como raíz del árbol de control.
Las solicitudes reales de la página se procesan mediante una serie de pasos. Primero, 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 siguientes pasos. Como cada nodo en el á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. Finalmente, durante el paso de renderizado, se utiliza un visitante para visitar cada nodo del árbol, pidiéndole a cada nodo que se renderice usando 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. Esta 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 . Como tal, si una aplicación utiliza interacción con estado, debe implementar la gestión del estado por sí sola. ASP.NET proporciona varias funciones para la gestión del estado. Conceptualmente, Microsoft trata el "estado" como el estado de la GUI . Pueden surgir problemas si una aplicación debe rastrear el "estado de los datos"; por ejemplo, una máquina de estado finito que puede estar en un estado transitorio entre solicitudes ( evaluación diferida ) o que tarda mucho en inicializarse. La gestión del estado en páginas ASP.NET con autenticación puede dificultar o imposibilitar el web scraping .
El estado de la aplicación lo mantiene una colección de variables compartidas definidas por el usuario. Estos se configuran e inicializan cuando el Application_OnStartevento se activa al cargar la primera instancia de la aplicación y están disponibles hasta que sale 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 su nombre. [10] La aplicación es la gestión estatal.
El estado de la sesión del lado del servidor lo mantiene 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 la sesión en la propia URL. [10]
ASP.NET admite tres modos de persistencia para variables de sesión del lado del servidor: [10]
El estado de sesión de ASP.NET le permite almacenar y recuperar valores para un usuario mientras este 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 navegador durante un período de tiempo limitado como sesión y proporciona una manera de conservar los valores de las variables durante la duración de esa sesión. De forma predeterminada, el estado de la sesión ASP.NET está habilitado para todas las aplicaciones ASP.NET.
Las alternativas al estado de sesión incluyen las siguientes:
El estado de vista se refiere al mecanismo de administración del 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 del formulario web . El estado de los controles se codifica y se envía al servidor cada vez que se envía un formulario en un campo oculto conocido como __VIEWSTATE. El servidor devuelve la variable para que, cuando se vuelva a representar la página, los controles se muestren en su último estado. En el lado del servidor, la aplicación puede cambiar el estado de visualización, 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 que utilizan la ViewStatecolección. [11]
El uso principal de esto es preservar la información del formulario en las devoluciones de datos. El estado de visualización está activado de forma predeterminada y normalmente serializa los datos en cada control de la página, independientemente de si realmente se utilizan durante una devolución de datos. Sin embargo, este comportamiento puede (y debe) modificarse, 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 Ver de una página o control, ya que la cadena Base64 que contiene los datos del estado de la vista se puede deserializar fácilmente. De forma predeterminada, Ver estado no cifra el __VIEWSTATEvalor. El cifrado se puede habilitar en todo el servidor (y en un servidor específico), 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 también se puede utilizar para almacenar varios objetos. El objeto "Caché" guarda los datos sólo durante un período de tiempo específico.
Otros medios de administración de estado que admite 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 definirían una nueva clase base que hereda de " System.Web.UI.Page", escribirían allí métodos que representen HTML y luego harían que las páginas de su aplicación hereden de esta nueva clase. Si bien esto permite reutilizar elementos comunes en un sitio, agrega complejidad y combina el código fuente con el marcado . Además, este método sólo puede probarse visualmente ejecutando la aplicación, no mientras 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, pueden anidarse. [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 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 completa la página de contenido. El resto de la página está definido por las partes compartidas de la página maestra, muy parecido a una combinación de correspondencia en un procesador de textos . Todos los controles de servidor y marcado en la página de contenido deben colocarse dentro del control ContentPlaceHolder.
Cuando se realiza una solicitud para una página de contenido, ASP.NET fusiona el resultado de la página de contenido con el resultado de la página maestra y envía el resultado al usuario.
La página maestra permanece totalmente 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 del directorio ASP.NET puede determinarse según las preferencias del desarrollador. Aparte de algunos nombres de directorios reservados, el sitio puede abarcar cualquier número de directorios. La estructura suele reflejarse 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]
ASP.NET busca obtener beneficios de rendimiento sobre otras tecnologías basadas en scripts (incluido ASP clásico) al compilar 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 o ensamblados dll contienen Microsoft Intermediate Language (MSIL) para ejecutarse dentro de Common Language Runtime ; esto proporciona un aumento de rendimiento sobre los lenguajes de script puro y es similar al enfoque utilizado por Python y no muy diferente de 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 los beneficios de rendimiento de un binario compilado. Sin embargo, la compilación puede causar un retraso notable pero breve para el usuario cuando la página recién editada se solicita por primera vez desde el servidor web, pero no nuevamente a menos que la página solicitada se actualice más.
El 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, es posible que se modifique 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 la necesidad de una compilación justo a tiempo 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 texto precompilado.
ASP.NET WebForms simplifica la transición de los desarrolladores del desarrollo de aplicaciones de Windows al desarrollo web al ofrecer la capacidad 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 parecida a sus homólogos 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 enviada al navegador del usuario final.
ASP.NET WebForms anima al programador a desarrollar aplicaciones utilizando un modelo GUI controlado por eventos , en lugar de entornos de secuencias de comandos web convencionales como ASP y PHP . El marco combina tecnologías existentes como JavaScript con componentes internos como " ViewState " para llevar el estado persistente (entre solicitudes) al entorno web inherentemente sin estado .
Otras diferencias respecto al ASP clásico son:
