ASP.NET
ASP.NET está construido sobre el Common Language Runtime, permitiendo a los programadores escribir código ASP.NET usando cualquier lenguaje admitido por el .NET Framework.
Después del lanzamiento del Internet Information Services 4.0 en 1997, Microsoft comenzó a investigar las posibilidades para un nuevo modelo de aplicaciones web que pudiera resolver las quejas comunes sobre ASP, especialmente aquellas con respecto a la separación de la presentación y el contenido y ser capaz de escribir código "limpio".
El desarrollo inicial de XSP fue hecho usando Java,[4] pero pronto se decidió construir una nueva plataforma sobre el Common Language Runtime (CLR), pues ofrecía un ambiente orientado a objetos, recolección de basura y otras características que fueron vistas como características deseables.
Guthrie describió esta decisión como un "alto riesgo", pues el éxito de su nueva plataforma de desarrollo web estaría atado al éxito del CLR, que, como XSP, aún estaba en etapas tempranas de desarrollo, tanto así que el equipo XSP fue el primer equipo en Microsoft en enfocarse en el CLR.
Con el cambio al Common Language Runtime, XSP fue implementado en C# (conocido internamente como "Project Cool" pero mantenido en secreto para el público), y fue renombrado a ASP+, en este punto la nueva plataforma fue vista como el sucesor de Active Server Pages, y la intención fue proporcionar un medio fácil de migración para los desarrolladores ASP.
[7] Una vez que la marca ".NET" fue seleccionada en la segunda mitad del 2000. se cambió el nombre de ASP+ a ASP.NET.
[9] Los formularios web están contenidos en archivos con una extensión ASPX; en jerga de programación, estos archivos típicamente contienen etiquetas HTML o XHTML estático, y también etiquetas definiendo Controles Web que se procesan del lado del servidor y Controles de Usuario donde los desarrolladores colocan todo el código estático y dinámico requerido por la página web.
Microsoft recomienda que para realizar programación dinámica se use el modelo code-behind, o de respaldo, que coloca el código en un archivo separado o en una etiqueta de script especialmente diseñada.
Los nombres de los archivos code-behind están basados en el nombre del archivo ASPX tales como MiPagina.aspx.cs o MiPagina.aspx.vb (esta práctica se realiza automáticamente en Microsoft Visual Studio y otros entornos de desarrollo).
Esto es similar a la separación en el Modelo Vista Controlador La etiqueta superior es colocada al inicio del archivo ASPX.
En este ejemplo, la directiva @ Page está incluida en EjemploCodeBehind.aspx y el archivo EjemploCodeBehind.aspx.cs contendrá el código para esta página: En este caso, el método Page_Load() será llamado cada vez que la página ASPX sea solicitada al servidor.
Las aplicaciones ASP.NET son alojadas en un servidor web y se tiene acceso a ellas mediante el protocolo sin estado HTTP, que no guarda ninguna información sobre conexiones anteriores.
Por lo tanto, si la aplicación requiere interacción entre conexiones, tiene que implementar su propia administración del estado.
El estado de los controles es codificado y mandado al servidor en cada envío del formulario en un campo oculto conocido como __VIEWSTATE.
El estado de los controles individuales son decodificados en el servidor, y están disponibles para su uso en ASP.NET usando la colección ViewState.
Además, este método puede visualizarse únicamente al ejecutar la aplicación, no mientras se está diseñando.
[15] Las plantillas maestras contienen controles contenedores, llamados ContentPlaceHolders para indicar donde irá el contenido dinámico, además de HTML y JavaScript que será compartido a través de las páginas hijas.
Esto significa que la página de contenidos puede manipular los encabezados, cambiar el título, configurar la caché, etc.
Fue subsecuentemente incluido con la versión 3.5 del .NET Framework, que fue liberada junto con Visual Studio 2008 en noviembre de 2007.
Los servidores ahora pueden insertar el contenido a los clientes conectados al instante cuando estén disponible.
Algunas características que son virtudes en unos modelos de programación, pueden ser consideradas debilidades en el otro.
Además acostumbran ser menos gestionables y escalables que las demás aplicaciones.
