martes, 11 de diciembre de 2018
La pasada semana, en el contexto del evento Microsoft Connect(); 2018, se lanzaron las últimas versiones de la familia de productos "Core": .NET Core 2.2, ASP.NET Core 2.2 y Entity Framework Core 2.2.
En todos los casos son revisiones pequeñas y que no rompen nada de lo anterior, pero en cada uno de estos productos se han introducido mejoras que vale la pena conocer, por lo que, antes que nada, os recomiendo que echéis un vistazo a los artículos anteriores, que son los anuncios oficiales.
En este post vamos a ver rápidamente las novedades más destacables de ASP.NET Core 2.2.
Por un lado, se introduce la posibilidad de usar convenciones predefinidas para especificar los tipos de respuestas de las acciones de forma global (por ensamblado), por controlador o por acción mediante el uso de atributos como
Por defecto el framework incorpora las convenciones
¿Y para qué sirve esto? Pues básicamente para que herramientas como Swagger o los analizadores de código de los entornos de desarrollo puedan "entender" que es lo que hacen nuestras acciones y ayudarnos, por ejemplo, generando automáticamente documentación de nuestras APIs, generando código de clientes que la consuman, o para que los IDE nos informen mientras desarrollamos de posibles errores de programación.
Y hablando de analizadores de código, en ASP.NET Core 2.2 se han introducido algunos para mostrar warnings cuando estamos implementando controladores
Por último, también se ha mejorado el soporte de Problem Details, añadiendo información a los retornos HTTP 4xx, como un identificador que puede resultar útil para trazar el error en logs.
Además, se pone a disposición de los desarrolladores un servicio singleton llamado
Otra novedad interesante es la capacidad de inyectar código personalizado para transformar parámetros a la hora de generar rutas. Por ejemplo, podríamos hacer que una ruta generada con
El secreto de este incremento de rendimiento tan brutal está en sustituir la actual arquitectura en la que IIS actúa como proxy inverso hacia Kestrel, que es quien ejecuta nuestra aplicación, como se representa en el siguiente diagrama:
A partir de ASP.NET Core 2.2, por defecto pasaremos a un modo de hospedaje in process, donde nuestra aplicación se ejecuta dentro del worker de IIS (w3wp.exe), eliminando esa costosa conexión HTTP interna:
Cabe destacar además el esfuerzo que los amigos del proyecto BeatPulse han realizado para portar esta biblioteca, que ya proporcionaba funcionalidades similares para versiones anteriores de ASP.NET Core, a la nueva infraestructura. Esto proporciona a los desarrolladores paquetes para comprobar el estado de una gran variedad de servicios (SQL Server, Redis, Oracle, MySQL, SqLite, RabbitMQ, Azure...), push hacia sistemas de telemetría como Application Insights o Prometheus, webhooks, e incluso un interfaz de usuario para visualizar el estado del sistema.
Publicado en Variable not found.
En todos los casos son revisiones pequeñas y que no rompen nada de lo anterior, pero en cada uno de estos productos se han introducido mejoras que vale la pena conocer, por lo que, antes que nada, os recomiendo que echéis un vistazo a los artículos anteriores, que son los anuncios oficiales.
En este post vamos a ver rápidamente las novedades más destacables de ASP.NET Core 2.2.
Mejoras para Web API
Como recordaréis, ya en ASP.NET Core 2.1 se introdujeron algunas novedades orientadas a facilitar la alineación de nuestras API Web con Open API/Swagger, como el filtro[ApiController]
, la clase ActionResult
o el soporte básico para Problem Details (RFC 7807). ASP.NET Core 2.2 continúa profundizando en esta línea añadiendo algunas características interesantes.Por un lado, se introduce la posibilidad de usar convenciones predefinidas para especificar los tipos de respuestas de las acciones de forma global (por ensamblado), por controlador o por acción mediante el uso de atributos como
ApiConventionType
o ApiConventionMethod
.Por defecto el framework incorpora las convenciones
DefaultApiConventions
, que básicamente permiten especificar los códigos HTTP de retorno que utilizarán las habituales acciones de tipo CRUD (por ejemplo, una acción llamada Create
retornará códigos 201-Created o 400-Bad request), pero también podemos crear convenciones personalizadas de forma muy sencilla.¿Y para qué sirve esto? Pues básicamente para que herramientas como Swagger o los analizadores de código de los entornos de desarrollo puedan "entender" que es lo que hacen nuestras acciones y ayudarnos, por ejemplo, generando automáticamente documentación de nuestras APIs, generando código de clientes que la consuman, o para que los IDE nos informen mientras desarrollamos de posibles errores de programación.
Y hablando de analizadores de código, en ASP.NET Core 2.2 se han introducido algunos para mostrar warnings cuando estamos implementando controladores
ApiController
cuya documentación no corresponda con lo que dice su código. Por ejemplo, en la siguiente animación se observa cómo se sugiere añadir el atributo [ProducesResponseType(404)]
a una acción que retorna un NotFound()
:Por último, también se ha mejorado el soporte de Problem Details, añadiendo información a los retornos HTTP 4xx, como un identificador que puede resultar útil para trazar el error en logs.
Mejoras en routing
Aunque aún se espera que esto cambie un poco para ASP.NET Core 3.0 (prevista para el año que viene), de momento en la versión 2.2 se han introducido algunas mejoras internas para conseguir un aumento importante de rendimiento en el proceso de selección de acciones o, en general, endpoints.Además, se pone a disposición de los desarrolladores un servicio singleton llamado
LinkGenerator
que podemos utilizar para generar rutas hacia nuestras acciones (de momento, sólo a acciones, aunque se ampliará el alcance en la versión 3.0) desde cualquier parte de nuestra aplicación. Aunque es conceptualmente similar a otros componentes como IUrlHelper
, se puede utilizar desde fuera de MVC (por ejemplo, en un middleware) y no requiere de un HttpContext
.Otra novedad interesante es la capacidad de inyectar código personalizado para transformar parámetros a la hora de generar rutas. Por ejemplo, podríamos hacer que una ruta generada con
Url.Action("get", new { product='MacBookAir' })
se transforme en /products/mac-book-air
. Podéis ver un ejemplo en este post de Hanselman.Hosting in-process
Tras mucho tiempo de desarrollo y varias marchas atrás a la hora de incluirlo en una release oficial, por fin tenemos una versión mejorada de módulo ASP.NET Core para IIS que promete cuadruplicar el rendimiento de nuestras aplicaciones cuando se ejecutan sobre este servidor web.El secreto de este incremento de rendimiento tan brutal está en sustituir la actual arquitectura en la que IIS actúa como proxy inverso hacia Kestrel, que es quien ejecuta nuestra aplicación, como se representa en el siguiente diagrama:
A partir de ASP.NET Core 2.2, por defecto pasaremos a un modo de hospedaje in process, donde nuestra aplicación se ejecuta dentro del worker de IIS (w3wp.exe), eliminando esa costosa conexión HTTP interna:
Nota: ojo si desplegáis en Azure y vais a upgradear rápidamente vuestra aplicación sólo por tener este incremento de rendimiento. El nuevo módulo ASP.NET Core no estará disponible en los App Services hasta ya bien entrado Diciembre, por lo que de momento tendremos que seguir usando el modelo out of process anterior.
Health monitoring
ASP.NET Core incluye ahora mecanismos para comprobar la salud de los componentes de nuestra aplicación (servidores, contenedores, servicios...). Aunque se pueden utilizar en cualquier tipo de proyecto, sin duda es especialmente interesante en entornos que requieren este tipo de comprobaciones, como orquestadores o balanceadores de carga que comprueban periódicamente el correcto funcionamiento de los servicios y son capaces de tomar medidas, como el reinicio de un contenedor o redirigir el tráfico, en caso de existir problemas.Cabe destacar además el esfuerzo que los amigos del proyecto BeatPulse han realizado para portar esta biblioteca, que ya proporcionaba funcionalidades similares para versiones anteriores de ASP.NET Core, a la nueva infraestructura. Esto proporciona a los desarrolladores paquetes para comprobar el estado de una gran variedad de servicios (SQL Server, Redis, Oracle, MySQL, SqLite, RabbitMQ, Azure...), push hacia sistemas de telemetría como Application Insights o Prometheus, webhooks, e incluso un interfaz de usuario para visualizar el estado del sistema.
Otras mejoras
Además de lo anterior, también cabe destacar las siguientes mejoras:- Incremento del rendimiento de hasta el 15% en validaciones del modelo.
- Incremento del rendimiento entre el 20% (Windows) y 60% (Linux) al usar HTTP client.
- Actualizadas las plantillas de proyecto a Bootstrap 4 y Angular 6.
Publicado en Variable not found.
2 Comentarios:
Que tal, he buscado algo sobre como acceder a archivos de mi servidor con asp MVC .net core pero no logro hacer match con mi problema, sabes algo tu sobre como puedo realizarlo?, saludos...
Hola!
A ver si esto te ayuda: https://www.variablenotfound.com/2016/03/archivos-estaticos-en-aspnet-core-1.html
Saludos!
Enviar un nuevo comentario