Ventajas y desventajas de ASP.NET Core

Como continuación del artículo en el que hablábamos de qué es más apropiado para los contenedores Docker: .NET Core o .NET Framework, veamos con más detalle las ventajas y desventajas de ASP.NET Core.

Al ser una empresa de desarrollo .NET, tenemos claro que .NET Core y ASP.NET Core son dos tecnologías independientes que se parecen y se diferencian como .NET Framework y ASP.NET. En este artículo, repasaremos la historia, las ventajas y las desventajas tanto de ASP.NET Core como de .NET Core. Además, repasaremos algunos cambios que se produjeron en la arquitectura del proyecto ASP.NET Core, basándonos en la revisión de los programadores de ASP.NET.

¿Qué son .NET Core y ASP.NET Core y por qué se crearon?

Millones de desarrolladores han utilizado y siguen utilizando ASP.NET 4.x para crear aplicaciones web. Es una gran tecnología que tiene una larga historia de desarrollo, que se remonta a su primera versión a principios de 2002. Desde entonces han cambiado muchas cosas para adaptarse a estos cambios, incluido el propio marco de trabajo. Hay al menos unas cuantas razones principales que han dado lugar a la creación de un nuevo marco desde cero.

En primer lugar, durante muchos años Microsoft ha estado proporcionando software de código cerrado, y esto disuadió a muchos desarrolladores que eran partidarios del código abierto. Algunos de los socios de Microsoft tenían acceso al código fuente, que obviamente no es lo mismo que el código abierto. Aunque no se contribuya al código fuente, el acceso al mismo puede ayudar a comprender con claridad cómo funciona exactamente el marco de trabajo y qué hace la función concreta del sistema. También permite que la comunidad contribuya al proceso de desarrollo: mejoras fáciles, discusiones rápidas, resolución de problemas. Es lo que los desarrolladores no tenían antes.

En segundo lugar, el marco .NET es compatible con una plataforma concreta, por lo que no es de extrañar que la gente lo asocie únicamente con Windows. Este hecho también fue un gran inconveniente para las personas que no pueden o no quieren utilizar el sistema operativo Windows

En tercer lugar, .NET Framework ha rechazado gradualmente la idea de separar completamente las instalaciones paralelas al no tener separación entre la versión menor y a veces incluso la mayor. Por ejemplo, las aplicaciones con dos versiones diferentes de .NET Framework coexistirán con el riesgo de compartir dependencias, lo que puede causar problemas. En cuanto a ASP.NET, que se basa en System.Web.dll, su arquitectura refleja estrechamente la forma en que el IIS procesa las solicitudes. Por ello, la segregación de ASP.NET de IIS es casi imposible hoy en día. Además, System.Web contiene muchas características en un solo módulo, lo que dificulta la modularización de la funcionalidad y el cambio del comportamiento a nivel de sistema de ASP.NET. No se puede obtener sólo una parte de la funcionalidad que se necesita: se obtiene todo en uno o no se obtiene nada

Todas estas razones empujaron a repensar y cambiar el enfoque de cómo debe avanzar la plataforma .NET. Así es como se crearon .NET Core y ASP.NET Core. Ambos tienen un Core en el nombre por una razón. Se hizo para evitar la impresión de que era sólo una nueva actualización del marco .NET y para enfatizar su idea de cambiar el concepto mismo. A pesar de todos estos hechos, no hace que sus habilidades actuales queden obsoletas. Sólo es una inversión importante en el futuro de toda la plataforma.

Ventajas de ASP.Net Core

Como se ha mencionado anteriormente, ASP.NET Core es un nuevo marco de trabajo de código abierto, modular, multiplataforma, extensible, asíncrono y mucho más ligero. Ahora es el único marco que se ejecuta sobre el tiempo de ejecución de .NET Core 5 (Core-CLR) o el tiempo de ejecución de .NET Framework (CLR) y tiene muchas ventajas, la mayoría de las cuales revisaremos a continuación.

NuGet

En contraste con el marco monolítico de .NET, la plataforma .NET Core es como un conjunto de paquetes NuGet que proporcionan una pequeña y discreta pieza de funcionalidad. Le permite optimizar las aplicaciones, hacerlas más ligeras y mucho más delgadas. También puede enviar una versión privada del marco .NET Core para su aplicación específica sin riesgo de que otras versiones de la aplicación puedan cambiar el comportamiento de su aplicación
Ese es un valor clave de ASP.NET Core, que ya no se basa en System.Web.dll. Puede ejecutarse en varias versiones de .NET Core en la misma máquina. NuGet permite al equipo de ASP.NET proporcionar nuevas funcionalidades y correcciones de forma mucho más fácil y rápida. De este modo, si Microsoft proporciona una actualización de alguno de los paquetes, sólo tiene que actualizarlo y ya está. Con ASP.NET Core 2.1, Microsoft ha introducido un metapaquete llamado Microsoft.AspNetCore.App, que contiene todas las bibliotecas enviadas por los equipos de .NET y ASP.NET, y proporciona soporte directo sin encerrarle en versiones específicas de las dependencias de terceros. Todo ello mejora el rendimiento y la escalabilidad de las aplicaciones.

Código abierto

.NET Core y ASP.NET Core son ahora de código abierto. Es un gran paso adelante para toda la comunidad .NET porque hace que el proceso de desarrollo sea transparente y limpio, permitiendo a los desarrolladores participar en la revisión del código, la corrección de errores, la aportación de nuevas características y la oportunidad de estudiar en detalle las bibliotecas utilizadas. Lo uno implica lo otro, y el código abierto permite a Microsoft extender la unificación de .NET también al desarrollo multiplataforma. .NET Core tiene una única base de código que puede utilizarse para construir y dar soporte a todas las plataformas, incluyendo Windows, Linux y Mac OS. Obviamente, algunos componentes individuales, como el sistema de archivos específico del sistema operativo, requieren una implementación independiente. El modelo de entrega a través de NuGet permite abstraer esas diferencias

Una sola API

La parte importante de esto para los desarrolladores es que se trata de una única API que funciona en diferentes plataformas. No necesitan ocuparse de ello, ya que el paquete ya contiene diferentes implementaciones para cada uno de los entornos. Las funciones de configuración también se han hecho más fáciles de usar entre plataformas al sustituir las antiguas por archivos JSON o INI y variables de entorno. La multiplicidad de plataformas también significa que tiene una gama más amplia de sistemas operativos que puede utilizar para la implementación, ya que Azure admitirá ASP.NET Core tanto en máquinas virtuales de Linux como de Windows. Depende de usted qué elegir.

Código de Visual Studio

Como un gran plus para aquellos que no quieren instalar Visual Studio , ahora también puede elegir Visual Studio Code, Atom, Emacs, o incluso trabajar con símbolo del sistema. Por ejemplo, Visual Studio Code es el editor de código multiplataforma para Linux, MacOS y Windows. T le permite construir, depurar y ejecutar aplicaciones web ASP.NET Core, aplicaciones web Node o aplicaciones de consola .NET Core con la posibilidad de utilizar IntelliSense, finalización de código e integración Git. Si usted es un partidario de las herramientas de línea de comandos, se alegrará de saber que todo lo que conlleva la construcción, compilación o ejecución de aplicaciones .NET Core puede realizarse mediante la línea de comandos.

Ventajas de rendimiento

Debido a que ASP.NET Core ocupa menos espacio, también hay algunas ventajas de rendimiento que son específicas de .NET Core, pero la mayoría de ellas se aplican tanto a .NET Framework como a .NET Core.

En cuanto a la ligazón de ASP.NET e IIS, ahora ASP.NET Core en realidad no requiere IIS para ejecutarse. Va con las siguientes implementaciones de servidor:

• Kestrel es el servidor HTTP predeterminado y multiplataforma para ASP.NET Core;
• IIS HTTP Server (IISHttpServer) es una implementación de servidor en proceso de IIS que se utiliza con el módulo ASP.NET Core;
• HTTP.sys es un servidor HTTP sólo para Windows basado en el controlador del núcleo HTTP.sys y la API del servidor HTTP.

El más popular entre ellos es Kestrel y también es uno de los predeterminados en las plantillas de ASP.NET Core. Cuando se crea un nuevo proyecto en Visual Studio, se configura automáticamente para que se ejecute en Kestrel. Este último se basa en realidad en libuv, que se utiliza para el trabajo de E/S y admite la ejecución de múltiples bucles de eventos. Sin embargo, a pesar de ser rápido, multiplataforma y de haber sido optimizado para el rendimiento de la ejecución, no proporciona toda la funcionalidad, ya que un servicio web con todas las funciones (como IIS) no ofrece la posibilidad de compartir puertos, la fácil configuración de SSL y la reescritura de URL. Algunas de estas características pueden aparecer en el futuro, pero hoy en día Kestrel se utiliza normalmente con un servidor proxy inverso, como IIS, Nginx o Apache. Esto es una ventaja y una desventaja al mismo tiempo. Kestrel es realmente rápido, de hecho, seis veces más rápido que Node.js para operaciones estáticas y de texto plano, y proporciona un mejor rendimiento en el procesamiento de solicitudes, pero todo esto se consigue debido a que no es а servidor web con muchas características. Entonces, ¿por qué era necesario crear un servidor web de este tipo si todavía es necesario utilizar un servidor proxy? Porque sin él, usted no es capaz de iniciar su aplicación en diferentes plataformas sin cambios. Sin Kestrel en otros servidores web multiplataforma, el código de la aplicación ASP.NET Core habría cambiado para cada uno de estos servidores web para adaptarse a sus criterios de inicio.

Como puede ver, ASP.NET Core supone un cambio importante. Todavía puede utilizar marcos como MVC, Web API, SignalR, y su sintaxis no va a cambiar extremadamente, así como la lógica de negocio escrita con Entity Framework. También sigue siendo el mismo código C#, F#, etc., y el .NET Framework está detrás de todo esto. Al final, el objetivo último no era sustituir .NET Framework por .NET Core, sino añadir una alternativa para los desarrolladores, comprometer a la nueva comunidad, proporcionar una pila completamente nueva para adaptarse a los nuevos cambios en el desarrollo y ampliar la plataforma en el futuro.

Contras de ASP.NET Core

Algunas de las tecnologías de .NET Framework no están disponibles en la versión actual de .NET Core. En realidad, está previsto que algunas de ellas estén disponibles con versiones posteriores, pero otras podrían no salir nunca. A continuación encontrará una breve lista de los escenarios en los que no puede utilizar .NET Core:

• ASP.NET Web Forms y ASP.NET Web Pages. Sólo están soportados y proporcionados por el .NET Framework completo. En el hilo de GitHub puede encontrar una respuesta de uno de los desarrolladores de Microsoft que explica que no estaba previsto portar WebForms a ASP.NET Core.
• Implementación de servicios WCF. Este escenario podría considerarse para futuras versiones de .NET Core, pero ahora, la respuesta más precisa sería “No, actualmente no está disponible para .NET Core”. La única biblioteca disponible es WCF-Client, que es adecuada para “dispositivos móviles o en servidores de nivel medio para comunicarse con servicios WCF existentes”, como dice su página de GitHub.
• Los servicios relacionados con el flujo de trabajo incluyen Windows Workflow Foundation (WF), Workflow Services (WCF + WF en un solo servicio) y WCF Data Services (antes conocido como ADO.NET Data Services). Actualmente no hay planes para llevarlos a .NET Core.
• Las aplicaciones Windows Forms y Windows Presentation Foundation (WPF) aún no son compatibles. Sin embargo, la gran noticia es que a principios de este año Microsoft anunció que tenía previsto lanzar la primera versión preliminar de .NET Core 3 a finales de este año y la definitiva en 2019. Esta nueva versión incluirá la posibilidad de ejecutar aplicaciones de escritorio de Windows nuevas y existentes en .NET Core. y le permitirá disfrutar de todas las ventajas que ofrece .NET Core. El soporte para el escritorio de Windows se añadirá como un conjunto de “paquetes de escritorio de Windows”, que sólo funcionarán en Windows.
• Falta el soporte de bibliotecas de terceros. .NET Core 2.0 proporciona un calce de compatibilidad entre .NET Framework y .NET Core, pero todavía puede tener algunos problemas de compatibilidad si la biblioteca de clases utiliza alguna API de .NET Framework que no sea compatible.
• No puede utilizar las API específicas de Windows en ASP.NET Core y .NET Core, ya que estos marcos están diseñados para ser más independientes del sistema operativo. Por ejemplo, no puede utilizar el espacio de nombres System.Drawing ni trabajar con el Registro de Windows, para ello debe utilizar el .NET Framework.

Hay muchas discusiones en los hilos de GitHub sobre el tema de la portación de las bibliotecas de .NET Framework a .NET Core, y este es un muy buen ejemplo de cómo el código abierto puede influir en el desarrollo de proyectos. Si abre estos hilos, verá que en cada tema los empleados de Microsoft responden sobre los planes de portar tecnologías, discuten los propósitos por los que necesitaban esta portación para saber qué es exactamente lo que necesitan los desarrolladores. Obviamente, habrá tecnologías que no se portarán en absoluto, ya que están relacionadas con el sistema operativo Windows cuando .NET Core se hizo para proporcionar soporte multiplataforma.

Ahora, cuando hayamos revisado todos los cambios importantes en .NET Core y ASP.NET Core, pasemos a una nueva estructura de la aplicación y los cambios, que persisten en un nuevo tipo del proyecto.

Fundamentos de ASP.NET Core

En este apartado, crearemos un proyecto de prueba para revisar los cambios en la estructura sobre un ejemplo real. Asuma que ha creado al menos una vez un nuevo proyecto con Visual Studio, y revisaremos una opción de crear una nueva solución con el proyecto junto mediante una consola

Para crear una solución, abra la consola (utilizaremos Windows PowerShell, pero también puede utilizar el símbolo del sistema) y ejecute el siguiente comando:

Aquí dotnet new es un comando con el que puede crear un nuevo proyecto, archivo de configuración o una solución basada en la plantilla especificada con todas las dependencias necesarias. En él indicamos que queremos crear una Solución con una opción sln y añadimos una opción -n para establecer el nombre del proyecto. Si no se especifica el nombre, se establecerá automáticamente el nombre equivalente de la carpeta. También puede utilizar el comando dotnet new -l para obtener una lista de todas las plantillas disponibles. Después de ejecutar este comando, si abre la carpeta, verá una solución recién creada. En relación con la estructura estándar del proyecto, cree una nueva carpeta cerca de la solución de cualquier manera:

• manualmente en el explorador de archivos;
• en el PowerShell con el comando md CoreAppProj;
• en la consola de Linux con el comando mkdir CoreAppProj.

Entre en este nuevo directorio y cree el proyecto con el comando

La opción “m vc” significa que el tipo de proyecto será “ASP.NET Core Web App (Model-View-Controller)” y el nombre se establecerá con el nombre de la carpeta. Para vincular la solución y el proyecto vuelva a la carpeta de la solución y ejecute el siguiente comando

Si ahora abre el proyecto en el Visual Studio verá un proyecto estándar creado:

Si revisa los archivos del proyecto con atención, notará que el formato del archivo .csproj se ha simplificado en ASP.NET Core. Revisemos los principales cambios paso a paso.

Programa.cs

En ASP.NET Core, el punto de entrada a una aplicación es Startup.cs, y ya no tiene una dependencia de Global.asax. ASP.NET Core maneja la entrada a través del método Principal de Program.cs (similar a las aplicaciones de consola y la aplicación ASP.NET Core es en realidad una aplicación de consola) y el Inicio se carga a través de ahí:

El método “Main” utiliza WebHostBuilder, que sigue el patrón del constructor para crear un host de aplicación web. El constructor incluye:

• el método que inicializa una nueva instancia de la clase WebHostBuilder con valores predeterminados preconfigurados – CreateDefaultBuilder(args);
• el método que define la clase de inicio – UseStartup(). Al iniciar la aplicación, el entorno ASP.NET buscará una clase en el ensamblaje de la aplicación llamada Startup y la cargará. El nombre “Startup” es el nombre por defecto, pero puede renombrarlo como desee. Sólo se requiere la construcción estándar de esta clase.

Como hemos mencionado anteriormente, el servidor por defecto debe ser Kestrel y a menudo puede cumplir con la siguiente realización:

Ambos (realización anterior y en nuestro ejemplo) son buenos. Sólo tiene que saber que el uso del método “CreateDefaultBuilder” significa que se aplicará la siguiente configuración por defecto (proporcionada por la documentación oficial de Microsoft):

• utilizar Kestrel como servidor web y configurarlo mediante los proveedores de configuración de la aplicación;
• establecer el ContentRootPath al resultado de GetCurrentDirectory();
• cargue IConfiguration desde “appsettings.json” y “appsettings.[EnvironmentName].json”;
• cargar IConfiguration desde User Secrets cuando EnvironmentName es ‘Development’ utilizando el ensamblaje de entrada;
• cargar IConfiguración desde las variables de entorno;
• configura el ILoggerFactory para registrar en la consola y depurar la salida;
• habilita la integración de IIS;
• habilita la posibilidad de que los frameworks vinculen sus opciones a sus secciones de configuración por defecto.

Puede cambiar manualmente los parámetros y configurar otro servidor web. Los métodos Build y Run construyen el IWebHost que alojará la aplicación y la ponen a la escucha de las peticiones HTTP entrantes.

Startup.cs

El método UseStartup de WebHostBuilder define la clase Startup de la aplicación, donde se define el canal de peticiones de la aplicación y donde se configuran todos los servicios. Un startup debe incluir un método Configure donde se añade el middleware necesario al pipeline. A continuación se muestra un fragmento de código generado que debería ver después de crear un proyecto:

ConfigureServices define los servicios utilizados por la aplicación y Configure define el middleware en el pipeline de peticiones. En el ejemplo anterior, el método Configure configura el pipeline con soporte para:

• Páginas de error;
• Seguridad de transporte estricta HTTP;
• Redirección HTTP a HTTPS;
• ASP.NET Core MVC.

Middleware

Los middlewares de ASP.NET Core son las piezas de código que realizan la lógica asíncrona en un HttpContext. Las solicitudes entrantes pasan a través de la tubería donde cada middleware invoca el siguiente middleware en la tubería o termina la solicitud. Los middleware pueden realizar cualquier tipo de operaciones, como manejar la autenticación, los errores, los archivos estáticos, etc. Por ejemplo, MVC en ASP.NET Core también se implementa como middleware. En realidad, puede crear middleware personalizado o utilizar el necesario de un enorme conjunto de middleware incorporado, y puede escribir su propio middleware personalizado. En el ejemplo anterior los middlewares son:

• UseDeveloperExceptionPage – permite ver información detallada de las excepciones. Se recomienda encarecidamente utilizarlo sólo en la puesta en escena. La llamada a este middleware debe colocarse antes del middleware en el que desee capturar las excepciones, por ejemplo, antes de app.UseMvc();
• UseExceptionHandler – configura una página de manejo de excepciones. Por lo general, se utiliza en producción en lugar de UseDeveloperExceptionPage, por lo que cuando el usuario obtiene un error, se mostrará la página, que usted especifica en este middleware;
• UseHsts – se utiliza para enviar las cabeceras del Protocolo de Seguridad de Transporte Estricto HTTP (HSTS) a los clientes;
• UseHttpsRedirection – se utiliza para redirigir las peticiones HTTP a HTTPS;
• UseStaticFiles – el método sin parámetros UseStaticFiles permite la funcionalidad de acceder a los archivos de la carpeta a través del navegador web. Por ejemplo, puede incluir la ruta de cualquier archivo de la carpeta wwwroot en el marcado y será visible para los usuarios. La carpeta wwwroot (/wwwroot) es el directorio por defecto, pero puede cambiarse manualmente;
• UseCookiePolicy – habilita las capacidades de la política de cookies en una aplicación. Además, sólo afecta a los componentes registrados después de él en el pipeline.

Configuración

ASP.NET Core también ha cambiado su modelo de configuración para manejar pares nombre-valor simples. El nuevo modelo de configuración se basa en pares clave-valor establecidos por los proveedores de configuración en lugar de depender de System.Configuration o web.config. Los proveedores de configuración pueden leer los datos de configuración desde una variedad de formatos de archivo: XML, JSON, INI, así como de variables de entorno, argumentos de línea de comandos o una colección en memoria. También puede escribir su propio proveedor de configuración personalizado. Por defecto, en su proyecto de prueba, que hemos creado anteriormente, debería ver el archivo JSON creado automáticamente con el nombre “appsettings.json”. Puede añadir la cadena de conexión en él, establecer los hosts permitidos y continuar.

Proveedor de configuración de variables de entorno

El nuevo modelo de configuración también permite utilizar variables de entorno a través de EnvironmentVariablesConfigurationProvider, que carga la configuración a partir de pares clave-valor de variables de entorno en tiempo de ejecución. Para activar la configuración de las variables de entorno, debe añadir la llamada al método de extensión AddEnvironmentVariables en una instancia de ConfigurationBuilder. Para activar la configuración de las variables de entorno, debe añadir llamar al método de extensión AddEnvironmentVariables en una instancia de ConfigurationBuilder. Cuando la aplicación se ejecute, se llamará al proveedor de configuración de variables de entorno justo después de que se establezca la configuración a partir de los secretos de usuario y los archivos de configuración de la aplicación. La llamada al proveedor en esta posición permite leer las variables de entorno en tiempo de ejecución para anular la configuración establecida por los secretos de usuario y los archivos appsettings.

Ejecución de la aplicación

Al principio de la sección, ya hemos revisado brevemente las formas de iniciar el desarrollo de aplicaciones mediante el uso de las herramientas de la CLI de .NET Core, por lo que ahora debe tener un proyecto para el que revisaremos algunos comandos más para terminar este tutorial de visión general.
Si comienza a buscar cualquier información sobre la ejecución de una aplicación a través de la CLI, podrá encontrar al menos 3 comandos:

• dotnet restore – llama a NuGet, que analiza el archivo CoreAppProj.csproj, descarga las dependencias definidas en el archivo (o las toma de una caché en su máquina), y escribe el archivo obj/project.assets.json, que es necesario para compilar y ejecutar el código;
• dotnet build – construye un proyecto y todas sus dependencias;
• dotnet run – ejecuta el código fuente.

En realidad, si está utilizando el SDK .NET Core 2.0, sólo tendrá que utilizar el último comando de esta lista. El comando dotnet restore se ejecuta implícitamente por todos los comandos que requieren un reinicio: dotnet new, dotnet build y dotnet run. Este comando se sigue utilizando en algunos casos, pero en este en particular, no es necesario. En cuanto al dotnet build, también es llamado por el comando dotnet restore para asegurar que los objetivos de construcción han sido construidos. Por eso, si ejecutamos el comando dotnet run, las dependencias del proyecto se descargan, el proyecto se construye y la aplicación se ejecuta. ¡Y eso es todo! Ahora puede empezar a utilizar estos conceptos básicos para crear una aplicación y mejorar sus habilidades.

Conclusión

.NET Core y ASP.NET Core incluyen muchas mejoras nuevas y cambios fundamentales que deberían ayudarle en el desarrollo diario. ¿Creería usted si alguien en el pasado dijera que Microsoft proporcionaría soluciones de código abierto y multiplataforma? Probablemente, no. Pero los tiempos cambian, y hoy en día Microsoft ofrece grandes soluciones que atraen cada vez a más desarrolladores. Por eso creemos que el futuro nos depara cambios aún mayores que trataremos en otros artículos