Las aplicaciones Asp.Net Core son aplicaciones de consola que configuran y ejecutan un WebHost.
En base a esto el ejemplo mínimo de un Hola Mundo en Asp.Net Core sería:
using Microsoft.AspNetCore.Hosting; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Http; namespace WebApplication { public class Program { public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .Configure(app => { app.Run(async (context)=>await context.Response.WriteAsync("Hola")); }) .Build(); host.Run(); } } }
El web Host no gestiona directamente las peticiones http. Eso es responsabilidad del servidor web. Asp.Net Core incluye un servidor multiplataforma llamado Krestel.
En el ejemplo anterior vemos que con .UseKestrel() indicamos configuramos el host para que use Krestel como servidor web.
Nuestro WebHost recibirá las peticiones web envueltas en un objeto de tipo httpContext.
En en el delegado async (context)=>await context.Response.WriteAsync("Hola") vemos qué hace la aplicación cuando recibe una petición web: Se recibe un objeto context del tipo httpContext. En este objeto escribimos en la respuesta el texto “Hola”.
En ningún momento se toma una decisión en base a la petición web (httpContext.Request) así que ante cualquier petición siempre hará lo mismo: responder con el texto “Hola”.
A la hora de pasar a producción una aplicación Asp.Net Core no deberíamos dejar al pequeño servidor web Krestel expuesto. Lo que recomienda Microsoft tenerlo detrás de otros servidores web más robustos, como puede ser el IIS en Windows o un nginx en Linux. Lo que me extraña es que ni mencionen apache, que también podríamos ponerlo por delante.
Con este ejemplo podemos ver las grandes diferencias que hay entre el modelo de Asp.Net Core y el modelo Asp.Net. Y es que Asp.Net Core ya no se basa en la librería System.Web.dll y eso cambia mucho todas las reglas de juego. Y en la medida de lo posible deberíamos evitar tener aplicaciones con pies de barro.
No hay comentarios:
Publicar un comentario