Forem: Brandon Ventura

ApiControllerAttribute en .NET Core

Brandon Ventura — Sat, 25 Jan 2025 13:41:24 +0000

Muchas veces dentro del desarrollo de Web APIs con .NET Core nos encontramos utilizando notaciones, recursos, atributos que vienen disponibles con el entorno y esto lo realizamos de manera prácticamente automática, en general, esto habla muy bien del trabajo por detrás del equipo encargado del mantenimiento de .NET, ya que como desarrolladores nos mantiene aislados de preocupaciones técnicas para enfocarnos en el desarrollo de funcionalidades del negocio.

Uno de estos pequeños componentes es el atributo ApiControllerAttribute que colocamos tan mecánicamente a nuestros controladores de API nada más crearlos, siendo una de las bondades disponibles y que en lo personal aportan tanto a la productividad en el desarrollo de Web APIs y uno de los que más me hacen falta cuando me encuentro dando mantenimiento a aplicaciones construidas sobre .NET Framework.

Antes de `ApiControllerAttribute`

Antes de .NET Core en .NET Framework no disponíamos de la clase o atributo ApiControllerAttribute, en realidad, no existe nada parecido en ASP .NET Framework (aunque podemos escribir filtros de acciones para lograr el mismo objetivo) y es importante no confundir este atributo con la clase ApiController en .NET Framework ya que esta clase proporciona la funcionalidad básica para procesar solicitudes HTTP a través de un conjunto de métodos y funcionalidades relacionadas con la escritura de controladores de Web API en .NET Framework más que modificar el comportamiento por defecto de estos controladores.

En ASP .NET Framework tenemos disponibles las clases Controller y ApiController cada una utilizada según el tipo de proyecto, Controller para controladores que principalmente realizan tratamiento de datos para el renderizado de vistas y ApiController para tratamiento de datos como servicios web o Web APIs.

Sin embargo, en .NET Core desde su primera versión vino con una sola clase unificada para los controladores, esta es la clase Controller que combina las clases Controller, ApiController y AsyncController de ASP .NET Framework MVC y Web API. Además de la clase Controller .NET Core añade la clase ControllerBase de la cual hereda Controller. ControllerBase provee la funcionalidad básica para manejo de solicitudes HTTP pero no incluye el soporte de vistas y todo lo relacionado con estas que sí tiene la clase Controller.

Si lo ponemos sobre el papel en .NET Core, la clase ControllerBase sería lo mismo que ApiController y Controller lo mismo que la clase Controller de .NET Framework, salvando las grandes diferencias que hay.

La clase ApiController estuvo disponible en .NET Core hasta la versión 2.2 y además, por si te da curiosidad, sí, en ASP .NET Framework existe una clase llamada ControllerBase que contiene lo mínimo necesario para todos los controladores de vistas, pero no es una clase utilizada para crear controladores que respondan a solicitudes HTTP directamente.

Entonces, ¿Para que sirve el `ApiControllerAttribute`?

Agregar la anotación o atributo ApiControllerAttribute a los controladores, nos brinda un conjunto de características y comportamientos que ayudan a mejorar el trabajo de los desarrolladores dentro de estos, reduciendo la cantidad de código innecesario o repetitivo dentro del controlador y sus acciones.

Agregar el atributo nos brinda la capacidad de: enrutamiento, validación automática/implícita de modelos, parameter binding mediante inferencia, entre otras cosas.

¿Cómo se utiliza?

Tenemos tres formas de utilizar el atributo:

Controladores individuales.
Desde una clase base.
Al ensamblado completo (Assembly).

Controladores individuales

Para agregarlo a nuestros controladores individuales debemos colocarlo sobre la definición de la clase del controlador, esto habilitará las características que dispone el atributo para nuestro controlador.

[ApiController]
[Route("[controller]")]
public class PersonasController: ControllerBase
{
    // Endpoints
}

Con una clase base

Debemos crear una clase que disponga del uso del atributo y herede de ControllerBase, de esta manera podremos heredar nuestra clase base a múltiples subclases y así disponer el atributo a más de un solo controlador sin necesidad de constantemente colocarlo sobre la definición del tipo de nuestro controlador.

// Clase base
[ApiController]
public class AppBaseController: ControllerBase
{
}

// Subclase
[Route("[controller]")]
public class PersonasController: AppBaseController
{
    // Endpoints
}

A todo el ensamblado

Por último, podemos aplicar el atributo a nivel de ensamblado, lo que lo agregara el atributo a todos los controladores del ensamblado; no se pueden excluir controladores específicos:

// Program.cs
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc;

[assembly: ApiController]
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

RouteAttribute

Si agregamos el atributo ApiControllerAttribute para decorar nuestros controladores, obligatoriamente debemos utilizar el atributo RouteAttribute para indicar la ruta a la que responderán las acciones del controlador.

[ApiController]
[Route("[controller]")]
public class PersonasController: ControllerBase

No podemos dejar que la ruta se defina mediante las rutas convencionales del método UseEndpoints, UseMvc o UseMvcWithDefaultRoute.

Validación Automática de Modelo

Cuando utilizamos el atributo [ApiController] todos los errores de validación, tipado y restricciones de nuestros modelos se aplican automáticamente devolviendo una respuesta HTTP 400 Bad Request; de esta forma la validación es implícita en lugar de explícita, es decir, no necesitamos agregar código que verifique si nuestro modelo es correcto:

[HttpPost]
public ActionResult CreatePets([FromBody]Pet pet)
{
    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    return Ok(pet);
}

Permitiendo eliminar así las siguientes líneas de las acciones de nuestro controlador:

if (!ModelState.IsValid)
        return BadRequest(ModelState);

En especial esto es lo que más aporta en cuanto a productividad cuando creamos nuestros controladores, ya que además de evitar repetir estas mismas líneas de código una y otra vez, evitamos que nuestros modelos pasen sin validar en caso que olvidáramos verificar si el ModelState es valido o no.

Si nosotros no validamos nuestro modelo explícitamente y tampoco hacemos uso del atributo ApiControllerAttributeASP .NET Core no nos alertará de que nuestro modelo es inválido o no contiene la información que debería.

La imagen anterior representa una respuesta de validación utilizando la validación explícita o manual. Si nosotros agregamos el atributo ApiControllerAttribute se ve de la siguiente manera:

Este mensaje de error es la respuesta HTTP 400 predeterminada utilizando el comportamiento definido por defecto gracias al ApiControllerAttribute. El tipo que utiliza es ValidationProblemDetails en lugar de BadRequestResult.

El tipo ValidationProblemDetails proporciona un formato que especifica los errores en las respuestas con mucho mayor detalle para humanos y máquinas y además cumple los requisitos establecidos por la RFC 7807.

Por ello, si realizamos validaciones personalizadas en las que tengamos que hacer uso del ModelState en nuestras acciones, es más conveniente hacer uso del método ValidationProblem(ModelState) en lugar de BadRequest(ModelState), o simplemente ValidationProblem() ya que usara la propiedad ModelState del controlador por defecto, de esta forma mantendremos todas nuestras respuestas consistentes:

if (!ModelState.IsValid)
    return ValidationProblem(ModelState);

A continuación puedes observar lo mencionado anteriormente:

[ApiController]
[Route("[controller]")]
public class PersonasController: ControllerBase
{

    /// <summary>
    /// Utiliza la validación explícita o manual del ModelState retornando un <see cref="BadRequestResult" />.
    /// </summary>
    [HttpPost("CrearPersona1")]
    public ActionResult CrearPersona1([FromBody] Persona persona)
    {
        if (!ModelState.IsValid)
            return BadRequest(ModelState);

        return Ok(persona);
    }

    /// <summary>
    /// Utiliza la validación explícita o manual del ModelState retornando un <see cref="ValidationProblemDetails" />
    /// </summary>
    [HttpPost("CrearPersona2")]
    public ActionResult CrearPersona2([FromBody] Persona persona)
    {
        if (!ModelState.IsValid)
            return ValidationProblem(); // es igual a return ValidationProblem(ModelState);

        return Ok(persona);
    }

    /// <summary>
    /// Deja que el atributo <see cref="ApiControllerAttribute" /> se encargue del comportamiento relacionado
    /// a la validación del ModelState.
    /// </summary>
    [HttpPost("CrearPersona3")]
    public ActionResult CrearPersona3([FromBody] Persona persona)
    {
        return Ok(persona);
    }
}

Invalid Model Response Customization

Si la respuesta estándar por defecto de los errores de validación aplicada mediante ValidationProblemDetails no cumple con nuestras necesidades o incluso queremos personalizarla, también lo podemos hacer.

Para ello debemos modificar el “comportamiento” de devolución de estas respuestas en nuestra API. ASP .NET Core provee una configuración especial para modificar el comportamiento de diversos aspectos de nuestra API, esto a partir del método ConfigureApiBehaviorOptions() sobre AddControllers() en los servicios de nuestra API.

En las opciones de configuración del método ConfigureApiBehaviorOptions() tendremos disponible la propiedad InvalidModelStateResponseFactory que recibe un delegado o callback mediante el cual podremos indicar nuestra respuesta personalizada.

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.InvalidModelStateResponseFactory = context =>
        {
            var newResponse = new
            {
                prop1 = "Propiedad 1",
                prop2 = "Propiedad 2"
            };
            return new BadRequestObjectResult(newResponse);
        };
    });

InvalidModelStateResponseFactory recibe de entrada un ActionContext que contiene la información del contexto para la ejecución de la acción que ha sido parte de esa solicitud HTTP, además, este delegado devuelve o debe devolver un IActionResult que determinara nuestra respuesta, en este caso un BadRequestObjectResult:

Lo anterior es un ejemplo básico, pero podemos personalizarlo a nuestro gusto, por ejemplo:

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.InvalidModelStateResponseFactory = context =>
        {
            var newResponse = new
            {
                path = context.HttpContext.Request.Path.ToString(),
                httpMethod = context.HttpContext.Request.Method,
                resource = (context.ActionDescriptor as ControllerActionDescriptor)?.ControllerName,
                endpoint = (context.ActionDescriptor as ControllerActionDescriptor)?.ActionName,
                errors = context
                    .ModelState
                    .ToDictionary(a => a.Key, a => a.Value?.Errors.Select(e => e.ErrorMessage))
            };
            return new BadRequestObjectResult(newResponse);
        };
    });

A partir del contexto ActionContext podemos obtener información referente al contexto HTTP de la solicitud, datos sobre el controlador y la acción ejecutada, el método de acción, la ruta y el ModelState para realizar el mapeo de la información de nuestro modelo, en este caso, la respuesta para un modelo inválido.

Al crear un nuevo delegado estamos sobrescribiendo la configuración por defecto de la propiedad InvalidModelStateResponseFactory.

Por defecto, utiliza la clase ProblemDetailsFactory que prácticamente devuelve una respuesta a partir de una instancia de ValidationProblemDetails.

Además, podemos incluir servicios dentro de este delegado, gracias a que ActionContext contiene el HttpContext de la solicitud, podemos solicitar los servicios disponibles dentro del contenedor de servicios de la solicitud, por ejemplo, podemos obtener el servicio de registro/trace/logs para guardar información referente a los errores de validación del modelo:

var logger = context.HttpContext.RequestServices.GetRequiredService<ILogger<Program>>();
logger.LogInformation("Hola desde modelo inválido!.");

También podemos desactivar estas respuestas automáticas completamente si configuramos la propiedad SuppressModelStateInvalidFilter a true.

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.SuppressModelStateInvalidFilter = true;
    });

Source Binding Inference Rules

Cuando nosotros aplicamos el atributo ApiControllerAttribute sobre nuestros controladores, esté provee una característica que permite inferir/determinar el origen/fuente de donde provienen algunos parámetros de acción sin la necesidad que nosotros como desarrolladores debamos colocar explícitamente el origen de los datos utilizando los atributos de enlace de datos, como puede ser FromBody, FromForm, FromQuery, etc.

ApiControllerAttribute aplica las siguientes reglas de inferencia:

Binding Attribute	Regla de Inferencia	Origen de enlace
`[FromBody]`	Inferido para cualquier tipo complejo, por ejemplo, las clases que nosotros mismos creamos. Si una acción hace referencia por inferencia o explícitamente a más de un parámetro desde el cuerpo de la solicitud, producirá una excepción.	Cuerpo de la solicitud.
`[FromForm]`	Inferido a partir de cualquier parámetro del tipo `IFormFile` o `IFormFileCollection`, por ejemplo, cuando hacemos envío de archivos como imágenes o documentos. Si el parámetro está contenido dentro de un tipo complejo definido por el usuario, no se realiza la inferencia, hay que indicar explícitamente la fuente de información.	Datos del formulario en el cuerpo de la solicitud
`[FromRoute]`	Inferido para cualquier parámetro de acción donde el nombre de la variable de parámetro coincida con un parámetro de ruta, es decir, aquellos que colocamos en la plantilla de ruta del endpoint o controlador.	A través de parámetros de consulta en la URI.
`[FromQuery]`	Inferido para cualquier otro parámetro de acción.	Desde la ruta de la solicitud actual, es decir, parte de la URI.
`[FromHeader]`	No hay una regla de inferencia para el enlace por encabezado.	Encabezado de la solicitud.
`[FromServices]`	Parámetros de tipo complejo que se encuentran registrados en el contenedor de dependencias.	Servicio de solicitud extraído del contenedor de dependencias

Si nosotros no hacemos uso del atributo ApiControllerAttribute y además no colocamos ningún atributo de enlace de modelo para la fuente, podemos tener comportamientos inesperados, como por ejemplo, un objeto complejo se espere a través de QueryString en lugar del Body o Payload de la solicitud.

Podemos desactivar todas las reglas de inferencia agregando la configuración SuppressInferBindingSourcesForParameters a true dentro del comportamiento de nuestra API:

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.SuppressInferBindingSourcesForParameters = true;
    });

Podemos deshabilitar la inferencia de servicios para un único parámetro de acción, aplicando el atributo correspondiente al origen del parámetro, en lugar de usar FromServices (por ejemplo, FromBody).

Por defecto, ApiControllerAttribute aplica la inferencia para los parámetros de tipo IFormFile y IFormFileCollection, el tipo de contenido de la solicitud multipart/form-data se infiere para estos dos tipos, de tal forma que agrega por defecto una restricción de acción donde los datos deben ser enviados con el tipo de contenido multipart/form-data, de esta manera los parámetros enlazados deben ser consumidos a partir de los datos de formulario (FormData).

Si queremos deshabilitar este comportamiento por defecto podemos cambiar la propiedad SuppressConsumesConstraintForFormFileParameters a true.

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.SuppressConsumesConstraintForFormFileParameters = true;
    });

Client Problem Details

ASP .NET Core realiza una transformación o mapeo a todos los resultados de error del cliente, es decir, cuando una se envía una respuesta con código de estado 400 o superior. Esta transformación por defecto se basa en la clase ProblemDetails que a su vez se basa en la misma especificación que ValidationProblemDetails, es decir, la RFC 7807 para respuestas de error con mayor detalle, es más, ValidationProblemDetails hereda de HttpValidationProblemDetails que a su vez hereda de ProblemDetails, por lo tanto, están dentro de la misma jerarquía de clases.

Un código de respuesta 404 Not Found se vería de la siguiente manera por defecto:

El método NotFound() dentro del controlador genera el código de estado HTTP 404, donde el cuerpo será un ProblemDetails.

Si queremos deshabilitar la respuesta por defecto de ProblemDetails de forma local, es decir, para un solo endpoint podemos sobreescribirlo enviando la sobrecarga del parámetro value que recibe el método NotFound():

return NotFound($"La persona que estas buscando no ha sido encontrada.");

La respuesta se vería de la siguiente manera:

Pero si queremos deshabilitar la respuesta de ProblemDetails para todos los códigos de estado de error, podemos cambiar el valor a true de la propiedad SuppressMapClientErrors dentro de las opciones de comportamiento del API:

builder.Services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.SuppressMapClientErrors = true;
    });

Con esto, al ocurrir un error y devolverse un código de estado de error del cliente no tendremos un cuerpo de respuesta por defecto, ya que hemos eliminado el mapeo de errores del cliente:

SuppressMapClientErrors por defecto es false, lo que hará que exista el mapeo, esto a su vez, agrega un filtro de resultado implícitamente a las acciones del controlador que transforman IClientErrorActionResult a una instancia de ProblemDetails que a su vez es devuelta como un ObjectResult que en su propiedad Value contiene una instancia de ProblemDetails.

Para personalizar la salida del filtro (por ejemplo, para devolver un tipo de error diferente), podemos registrar una implementación personalizada de IClientErrorFactory en la colección de servicios:

public sealed class AppClientErrorFactory(ILogger<AppClientErrorFactory> logger) : IClientErrorFactory
{
    private readonly ILogger<AppClientErrorFactory> _logger = logger;
    public IActionResult? GetClientError(ActionContext actionContext, IClientErrorActionResult clientError)
    {
        _logger.LogWarning("Error del cliente.");
        return new ObjectResult("ClientErrorFactory personalizado.") { StatusCode = clientError.StatusCode };
    }
}

Como podemos ver es una clase que simplemente implementa la interfaz IClientErrorFactory. El método GetClientError recibe el ActionContext que ya vimos anteriormente y además una instancia de IClientErrorActionResult de la cual podemos conocer el código de estado de la respuesta o procesar el resultado para modificarlo. En este caso simplemente se mapea a un ObjectResult y se utiliza el servicio de logs para registrar algo que sea de nuestro interés.

En esta clase podemos inyectar cualquier servicio que necesitemos ya que va a ser parte de nuestro contenedor de dependencias, por lo tanto debemos registrarlo como servicio Singleton en nuestro contenedor para reemplazar la implementación por defecto:

builder.Services.AddSingleton<IClientErrorFactory, AppClientErrorFactory>();

Ten en cuenta que si SuppressMapClientErrors es true, el IClientErrorFactory personalizado no será utilizado.

Conclusión

De esta manera hemos aprendido para qué sirve el atributo ApiControllerAttribute y como agregarlo a nuestros controladores de recursos para aplicar características y comportamientos predefinidos en ASP .NET Core. Además, hemos aplicado distintas configuraciones que permiten personalizar este comportamiento por defecto, como lo son la respuesta de validación de estado del modelo, códigos de error del cliente, restricciones sobre tipos de archivos, inferencia de tipos y más.

Código fuente

Recursos adicionales

https://code-maze.com/apicontroller-attribute-in-asp-net-core-web-api/

https://learn.microsoft.com/es-mx/aspnet/core/web-api/?view=aspnetcore-7.0#apicontroller-attribute

https://learn.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-9.0

https://learn.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api

Common Language Runtime (CLR) e Intermediate Language (IL)

Brandon Ventura — Sat, 02 Nov 2024 19:59:21 +0000

Cuando estamos trabajando con la plataforma de .NET tenemos una gran variedad de opciones en cuanto a lenguajes que podemos utilizar para crear nuestras aplicaciones, entre estos están C#, F# y Visual Basic que son los lenguajes más conocidos de la plataforma, aunque no los únicos, ya que además puedes utilizar, por ejemplo, C++, todo esto de manera interoperable, es decir, que puedes realizar tus programas en cualquiera de estos lenguajes y comunicar entre si partes del mismo escritas en los distintos lenguajes soportados por la plataforma.

Pero, te preguntaras ¿Cómo es todo esto posible? Es magia… O mas bien es la ingeniería por detrás de la plataforma de .NET que permite realizar programas utilizando diversidad de lenguajes en conjunto gracias a su entorno de ejecución mejor conocido como Common Language Runtime (CLR) y un lenguaje especial al cual se compilan nuestros programas hechos con .NET llamado Intermediate Language (IL).

Código Administrado y No Administrado

Antes de comenzar a conocer un poco mas sobre el CLR e IL, debemos conocer los conceptos de código administrado y no administrado, esto es importante de destacar ya que una de ambas es la forma en que se ejecutan nuestras aplicaciones en el sistema al cual han sido destinadas.

Código administrado

El código administrado o gestionado es como su nombre lo dice, cuando el código de nuestro programa, o mas bien los recursos que este utiliza son administrados por un componente adicional en su ejecución que, esto es, nuestro código ejecutándose bajo la supervisión de un entorno de ejecución o maquina virtual, que en el caso de .NET es el CLR la maquina virtual encargada de supervisar o administrar la ejecución de nuestro código y además gestionar el uso de los recursos que el sistema operativo brinda a nuestros programas, de lo cual se vera un poco mas a detalle cuando hablemos del CLR.

Esto significa que el código de la aplicación no se ejecuta directamente sobre el sistema operativo del dispositivo, sino que en vez de ello, se apoya de un ambiente de ejecución (runtime engine) para ser ejecutado, encargado de asignar recursos y servicios de soporte como seguridad, administración de la memoria, entre otros.

Este entorno de ejecución es conocido mas formalmente como maquina virtual de proceso o aplicación abreviado PVM (Process-level Virtual Machine) que se ejecuta como una aplicación cualquiera dentro del sistema y soporta un proceso individual e independiente dentro del sistema operativo permitiendo así que los lenguajes en los que fueron escritos nuestras aplicaciones se comuniquen con el sistema, siendo un intermediario entre el lenguaje y el código maquina.

Normalmente la PVM se crea cuando el proceso es iniciado y se detiene cuando finaliza el proceso, esto es importante, puesto que algunas optimizaciones que son realizadas solo persisten durante el ciclo de vida de dicho proceso.

Es importante mencionar el termino de PVM, ya que muchas veces asociamos al termino de maquina virtual solo a aquellas que permiten crear una capa adicional en nuestro sistema operativo para ejecutar sobre este otro sistema operativo virtualizado, esto ultimo se conoce como maquina virtual del sistema (System Virtual Machine) la cual su propósito es ejecutar un sistema operativo completo dentro del sistema operativo de nuestra maquina física o anfitriona.

Código no administrado

Es código que se ejecuta directamente en el sistema operativo, es decir, no existe ningún entorno de ejecución o maquina virtual intermedia para ser ejecutado, por lo tanto, es responsabilidad del desarrollador gestionar los recursos a los que acceden sus programas para que estos sean eficientes, aunque tienden a tener mayor rendimiento que aquellos con código administrado ya que esta capa intermedia no existe y por lo tanto el proceso de interpretar, compilar o transformar el código a código maquina durante el tiempo de ejecución no existe; los programas escritos en lenguajes que compilan directamente a código máquina como C o C++ serian ejemplos de código no gestionado aunque no significa que no podamos escribir código en C#, por ejemplo, no gestionado.

¿Cuál es la Mejor Opción?

Como vemos la diferencia principal entre ambos esta en sobre quien recae la responsabilidad de administrar los recursos del sistema como la memoria o los servicios que se requieran de este, en el caso del código administrado recae sobre el entorno de ejecución o maquina virtual correspondiente mientras que el código no administrado es responsabilidad del desarrollador cuidar estos aspectos.

La decisión sobre uno u otro dependerá del proyecto en cuestión, y, almenos cuando se desarrolla con .NET la mayoría de los casos de uso están cubiertos, por lo que lo mas común será trabajar con código administrado a través del CLR, permitiendo que la experiencia de desarrollo sea mucho mejor, mejorando la productividad y portabilidad de las aplicaciones.

Son pocos los casos en que es necesario salir fuera de lo convencional, aunque pueden existir como es el caso de los controladores de dispositivos (device drivers).

Si por la naturaleza del proyecto es imposible usar código administrado al cien por ciento, puede ser recomendable combinar ambos esquemas: se desarrollan como código no administrado los componentes que así lo requieran, y el resto se implementa como código administrado.

En cuanto a desempeño de la aplicación se refiere, los mejores resultados se pueden obtener usando código no administrado, sin embargo, con el paso del tiempo los lenguajes, herramientas disponibles y el hardware evolucionan lo que tiene como resultado que en muchas ocasiones las mejoras en rendimiento no serán notables, por lo que utilizar código administrado es prácticamente la opción predeterminada por el beneficio que esto aporta en cuanto a la experiencia de desarrollo que proporciona y la capacidad de ejecutar nuestras aplicaciones o programas en múltiples sistemas y arquitecturas, siempre y cuando el entorno de ejecución lo permita.

Common Language Runtime (CLR)

Su objetivo es el de proporcionar un entorno de ejecución independiente de la plataforma de hardware y del sistema operativo, que oculte los detalles de la plataforma subyacente y permita que un programa se ejecute siempre de la misma forma sobre cualquier plataforma. Esto es debido a que el código de máquina es específico al dispositivo siendo utilizado y programar a ese nivel requiere un conocimiento sobre el sistema operativo y la máquina. El CLR actúa como una máquina virtual, sirviendo de puente entre los lenguajes de alto nivel disponibles en .NET y el código de máquina que la computadora puede entender.

Si programamos en C#, el CLR, es a Java la JVM (Java Virtual Machine) salvando las diferencias entre ambas plataformas, siendo el ejemplo más conocido y cercano en lo que respecta, ya que su propósito es interpretar, compilar o traducir un código intermedio entre el lenguaje y código máquina.

De parte de Microsoft se refieren al CLR como un entorno de ejecución de código administrado (managed runtime environment) donde el cual los programas escritos en cualquiera de los lenguajes de la plataforma como Visual Basic, C# o F# después de ser compilados a Intermediate Language puedan ejecutarse en el CLR. Cuando tú escribes tu código en cualquiera de estos lenguajes estableciendo una versión del entorno a utilizar y lo compilas, lo que realmente estás haciendo es crear información descriptiva sobre el programa que es almacenada en el programa compilado como metadatos, estos metadatos están contenidos en archivos .exe y/o .dll más conocidos como ensamblados, los cuales se encontraran en lenguaje intermedio optimizado para su ejecución, toda esta información le dice al CLR el lenguaje en el cual fue escrito el programa, la versión, librerías de clases, referencias y todo aquello que el programa necesitará para su ejecución, lo que se conoce como aplicación autocontenida (self-contained application) teniendo todo lo necesario para su ejecución en cualquier máquina con el entorno de ejecución instalado.

De esta forma el CLR permite a tus programas que, por ejemplo, un objeto instanciado a partir de una clase escrita en un lenguaje pueda llamar al método de otra clase escrita en otro lenguaje.

Funciones del CLR

Administración de memoria a través del Garbage Collector.
Manejo de excepciones.
Seguridad de tipos.
Seguridad entre procesos.
Administración del código en ejecución.

Componentes del CLR

Compilador JIT (Just-In-Time Compilation).
Class loader.
Thread pool.

Intermediate Language (IL)

También conocido como Microsoft Intermediate Language (MSIL durante la beta de los lenguajes de .NET) o Common Intermediate Language (CIL) es el código generado a partir del proceso de compilación de nuestro programa escrito en el lenguaje de nuestra elección en la plataforma sin importar cual sea este.

El lenguaje intermedio es código que tiene un menor nivel de abstracción que los lenguajes como C# o F# (lenguajes de alto nivel) lo que lo hace un poco mas difícil de escribir, leer y manejar para los desarrolladores, pero es de mas alto nivel que el código máquina propiamente.

El lenguaje intermedio trabaja por medio de instrucciones que indican como posicionar o localizar cada uno de los elementos de nuestro programa manipulando así el stack o la pila de ejecución a través de estas instrucciones que indican la operación a realizar. Las instrucciones que componen un programa escrito en lenguaje intermedio son llamadas opcodes (abreviado de operation codes), estas instrucciones se encuentran en los metadatos generados al momento de compilar nuestro programa.

Lo que Microsoft busca a través del lenguaje intermedio es que tengamos la libertad de seleccionar cualquier lenguaje soportado por la plataforma de .NET y programar en este lenguaje sin preocuparnos de como este se ejecutara en cuestión, además de tener la capacidad de utilizar estos lenguajes en conjunto para crear nuestros programas. Esto lo consiguió creando el lenguaje intermedio siguiendo la especificación abierta y estándar técnico conocido como Common Language Infrastructure (CLI) permitiendo así que los programas escritos en cualquier lenguaje sean interoperables entre si y puedan ser ejecutados en distintos tipos de hardware; CLI a su ves incluye el Common Type System (CTS) y Common Language Specification (CLS).

Algunas implementaciones del CLI son .NET Framework, .NET (o .NET Core) y Mono.

Curiosidades sobre el CLR e IL

¿La compilación JIT realizada por el CLR se ejecuta por cada método, cada vez que se llama?

El código IL normalmente siempre es pasado por el compilador JIT cada vez que se ejecuta el programa, es decir, se compila en cada ejecución, pero cada pieza de código IL se compila una sola vez cuando es llamado y no vuelve a recompilarse nuevamente una vez ya se ha realizado esta única ocasión, por lo que no hay optimizaciones basadas en el uso o anteriores compilaciones.

Esto es, conforme los bits de los ensamblados son ejecutados el compilador JIT compila y cachea estos bits en memoria. De esta forma cada bit es solamente compilado una vez antes de su ejecución, luego se utiliza su versión nativa en memoria para su ejecución. Por esta razón la compilación JIT se realizara en cada ejecución del programa ya que como se almacena en memoria el resultado al finalizar el programa es que esta memoria es liberada de nuestro sistema operativo.

De manera simplificada, esto significa que la compilación ocurre una sola vez por método durante la ejecución del programa en la primera invocación de ese método y cuando el programa se detiene toda la compilación se pierde.

Es por esto que en muchos tutoriales, blogs o cursos habrás escuchado que mencionan que “al ejecutar la aplicación siempre tardara un poco mas en ejecutarse cuando llamas al método, porque aun no esta en memoria.”

¿Qué ocurre con los genéricos?

Los genéricos en .NET presentan un comportamiento particular respecto a la compilación JIT, ya que el CLR maneja su compilación de manera optimizada dependiendo del tipo con el que se instancien, es decir, si son tipos por valor (value types) o tipos de referencia (reference types) lo cual se explica a continuación:

Cuando un tipo genérico es instanciado con un tipo de valor (por ejemplo, int, float, struct, etc.), el CLR compila una versión específica del método genérico para cada tipo de valor con el que se instancie. Esto se debe a que los tipos de valor en .NET tienen un tamaño y representación diferentes en memoria, por lo que el código generado tiene que ser único para cada tipo de valor.
- Por ejemplo, la clase genérica List<T> la usas con List<int> y List<double>, el CLR generará dos compilaciones diferentes, una para int y otra para double.
Esto ocurre porque los tipos de valor son almacenados directamente en memoria, y la compilación específica optimiza cómo se manejan esos valores.
Cuando un tipo genérico es instanciado con un tipo de referencia (por ejemplo, string, object, o cualquier clase definida por ti), el CLR comparte una única versión compilada para todos los tipos de referencia. Es decir, la compilación JIT se realiza una vez para todos los tipos de referencia, ya que estos tipos son siempre manejados por referencias (punteros o direcciones de memoria), y la representación en memoria es uniforme para todos los tipos de referencia.
- Por ejemplo, si usas List<string> y List<object>, el CLR compilará una sola versión para los tipos de referencia y la reutilizará para ambos casos.

¿Cuándo se usa Reflection también se almacena en memoria el código compilado resultante mediante JIT?

En el caso de utilizar Reflection en .NET para invocar métodos sean genéricos o no, el código sí se compila mediante el JIT y se almacena en memoria:

Cuando invocas un método mediante Reflection, el CLR aún tiene que compilar el método desde IL a código máquina usando el JIT. Esto ocurre de la misma manera que si el método hubiera sido invocado directamente en el código.
Una vez que el método es compilado mediante el JIT, el código resultante se almacena en memoria para reutilizarlo en futuras invocaciones, incluso si el método fue invocado a través de Reflection.

El JIT compila el método la primera vez que es invocado y almacena el código nativo en memoria por lo que si vuelves a invocar ese mismo método con Reflection, el CLR reutiliza el código compilado, evitando recompilarlo.

Prácticamente lo que cambia es como invocas el método, que es estática o directa si llamas al método desde tu código de la forma convencional y dinámica o indirecta que es cuando utilizas Reflection escaneando los metadatos de los tipos para encontrar el método y ejecutarlo; para el CLR da igual la forma en que lo ejecutes, lo único que importa es que estas ejecutándolo y lo compilara a código nativo o maquina, sin embargo, ten en cuenta que usar Reflection afecta el rendimiento pero esto no tiene que ver con el CLR como tal sino mas bien con el uso de la inspección de tipos y el descubrimiento de los mismos en tiempo de ejecución mediante Reflection.

De esta forma una vez que el método es compilado a código nativo, tanto para invocaciones directas como para invocaciones con Reflection, el código compilado se guarda y se reutiliza. Esto significa que el proceso de compilación en sí no se repite, pero la parte dinámica de la invocación a través de Reflection (búsqueda e invocación) sigue siendo más lenta porque siempre se realizará.

Recursos adicionales

https://www.geeksforgeeks.org/common-language-runtime-clr-in-c-sharp/

https://en.wikipedia.org/wiki/Common_Intermediate_Language

https://www.artima.com/articles/clr-design-choices

https://snifftontechnologies.wordpress.com/2014/03/05/what-is-common-language-runtime-in-c/

Conociendo BenchmarkDotNet

Brandon Ventura — Sat, 14 Sep 2024 20:32:27 +0000

¿Cómo de eficiente es tu código?, ¿Los cambios que estas haciendo mejoran o empeoran tu aplicación en términos de rendimiento?. Tomar puntos de referencia comparativos (benchmarking) es importante para comprender como tu aplicación mejora o empeora y permitir así evaluar tu código.

Al momento de hacer pruebas evaluativas piensa en ellas como si fueran pruebas unitarias, no quieres evaluar interacciones complicadas a menos que este sea tu objetivo, por ello, un simple proyecto de consola es útil para poder visualizar las comparaciones del código de tu aplicación.

En esta ocasión haremos un overview de BenchmarkDotNet y como este nos ayuda a realizar pruebas comparativas o de referencia en nuestro código para tomar decisiones informadas desde el diseño hasta la implementación.

Primeros pasos

Lo primero que debemos realizar es tener una aplicación de consola, esta puedes crearla como cualquier otra aplicación de consola que hayas creado antes, solo ten en cuenta el soporte del paquete (puedes verlo en la pagina oficial BenchmarkDotNet):

Runtimes: Full .NET Framework (4.6+), .NET Core (2.0+), Mono, NativeAOT
OS: Windows, Linux, MacOS
Languages: C#, F#, VB
BenchmarkDotNet solo funciona con aplicaciones de consola (How to Run).

Una vez tengas lista la aplicación procede a instalar el paquete utilizando alguna de las siguientes formas:

Package Manager Console: Install-Package BenchmarkDotNet -Version 0.14.0
.Net CLI: dotnet add package BenchmarkDotNet --version 0.14.0. Recuerda que este comando debes especificar el archivo de proyecto .csproj al que instalaras el paquete o ubicar tu consola en la ruta donde se encuentre el .csproj del proyecto al que instalaras el paquete.
Interfaz del Package Manage: Si usas Visual Studio puedes instalar el paquete dando clic derecho sobre tu proyecto en el explorador de soluciones > Administrar Paquetes NuGet (Manage NuGet Packages) > Examinar > Buscar BenchmarkDotNet > Instalar.

Una vez listo esto podemos comenzar a escribir nuestro código.

Nuestro primer Benchmark

Lo primero que necesitamos es tener código que evaluar, en este caso haremos una simple concatenación de cadenas de texto, para ello creamos la siguiente clase:

public class BenchmarkDemo
{
    [Benchmark]
    public string ConcatenacionSimple()
    {
        string texto = "";
        for (int i = 0; i < 100; i++)
        {
            texto += i;
        }

        return texto;
    }
}

Esta clase contiene un método llamado ConcatenacionSimple que ejecuta un ciclo for 100 veces y concatena cada numero, aunque esto no es lo primordial, podría ser cualquier código que tu quieras comparar, lo importante a notar es el atributo BenchmarkAttribute que decora el método [Benchmark], este atributo permite marcar un método como método a comparar dentro de la clase, ahora solo necesitamos ejecutar nuestro benchmark, para ello escribimos el siguiente código:

var result = BenchmarkRunner.Run<BenchmarkDemo>();

Si utilizamos TLS (Top-Level Statements) nuestra clase Program.cs se veria de la siguiente forma:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

var result = BenchmarkRunner.Run<BenchmarkDemo>();

public class BenchmarkDemo
{
    [Benchmark]
    public string ConcatenacionSimple()
    {
        string texto = "";
        for (int i = 0; i < 100; i++)
        {
            texto += i;
        }

        return texto;
    }
}

Esto suponiendo que nuestra clase BenchmarkDemo este dentro del mismo archivo pero puede vivir en cualquier parte de nuestra solución (ensamblado, namespace, etc). Si no utilizamos TLS entonces tendríamos la estructura convencional de nuestra clase Program y dentro del método Main escribiríamos el runner de nuestro benchmark:

internal class Program
{
    static void Main(string[] args)
    {
        var result = BenchmarkRunner.Run<BenchmarkDemo>();
    }
}

Una vez listo esto podemos ejecutar nuestro código, sin embargo, el código debe de ser compilado en modo Release, esto es porque el modo Debug es una compilación que no esta totalmente optimizado para realizar las configuraciones ya que este modo utiliza y reserva algunos recursos adicionales para poder permitir depurar nuestro código durante el desarrollo, lo cual esta muy bien durante el desarrollo pero para comparar de manera eficiente nuestro código es necesario optimizar el uso de los recursos por ende utilizaremos el modo Release, podemos hacerlo de las siguientes dos formas:

.NET CLI: Ejecutamos el comando dotnet run --configuration Release. Al igual que durante la instalación del paquete recuerda que este comando debes especificar el archivo de proyecto .csproj al que instalaras el paquete o ubicar tu consola en la ruta donde se encuentre el .csproj del proyecto al que instalaras el paquete.
Visual Studio: Modificaremos el modo de ejecución desde el menú de herramientas en el IDE para seleccionar Release en el selector de Configuraciones de Soluciones. Luego, podemos ejecutar nuestra aplicación de consola.

Cualquiera de las opciones que sigas, ejecutara el proyecto en la configuración adecuada. Siempre que ejecutamos una aplicación o sistema por primera vez existe un costo de levantamiento o arranque inicial de esta, esto es debido a que todos los servicios, recursos, etc. que necesita la aplicación son “levantados” o inicializados durante este arranque inicial por lo que Benchmark.net lo que hace es ejecutarse unas cuantas veces como “calentamientos” antes de comenzar a tomar las ejecuciones como referencia descartando estas ejecuciones y luego comenzar a tomar los resultados una vez la aplicación ya haya pasado este periodo inicial de ejecución, piensa en ello como cuando tu harás tu rutina de ejercicio en casa, en el gimnasio o cualquier otro lugar y calientas un poco antes de comenzar dicha rutina.

El resultado te muestra la versión del paquete, el sistema operativo y la actualización de este, el procesador y tarjeta grafica, así como la cantidad de CPUs y procesadores lógicos y físicos y el entorno de ejecución. Esto es importante, porque de esta manera conocemos el entorno y recursos en donde nuestra aplicación o en este caso las pruebas están siendo ejecutadas para tenerlo como referencia o replicar estas pruebas.

Esto solo te esta haciendo saber respecto a donde se esta ejecutando esta prueba, pero no será lo mismo si lo ejecutas en otra máquina, sin embargo, en términos generales no te están diciendo el rendimiento general de tu código, solo te dicen que esta ejecutándose en tu maquina y que tan rápido se ejecuta en tu maquina, por lo que, no es tan útil si consideramos el proyecto ejecutándose en producción, pero primeros pasos son primeros pasos y estos son importantes.

Podemos agregar el atributo [MemoryDiagnoser] a nuestra clase BenchmarkDemo:

[MemoryDiagnoser]
public class BenchmarkDemo
{
    [Benchmark]
    public string ConcatenacionSimple()
    {
        string texto = "";
        for (int i = 0; i < 100; i++)
        {
            texto += i;
        }

        return texto;
    }
}

Este atributo permite agregar un diagnosticador para conocer cuanta memoria esta siendo utilizada o alojada por el método así como cada una de las generaciones que son creadas por el Garbage Collector y las recolecciones que este realiza para las operaciones:

De esta forma el benchmark identificara que tan eficiente es un método base en la ejecución del mismo un numero determinado de veces.

El resultado además nos indica las etiquetas o leyendas del resultado que pueden ser mas interesantes o menos según que tanto te gusten las matemáticas:

Quizá las mas relevantes son la media del tiempo de ejecución (Mean) la desviación estándar (StdDev) que nos permite estar seguros de si el tiempo de la media es significativo o si el tiempo de cada ejecución esta alejado de esta y la memoria alojada por ejecución (Allocated) nos dice cuanta memoria es alojada por llamada del método, en este caso, seria todo lo que almacenamos en nuestras variables.

Respecto a la columna Gen0 tiene que ver con el funcionamiento interno del Garbage Collector mas que con una simple métrica de BenchmarkDotNet. Gen0 es el GC diciendo “me ejecutare y me fijare en de las cosas que no son mas necesarias” luego de marcar todo aquello que no es necesario marca además los recursos que no puede eliminar porque están siendo utilizadas, de esta forma limpia la memoria de lo que ya no es útil y lo que sigue siendo útil lo marca o lo pasa a Gen1, lo que significa que sobrevivió una limpieza, la limpieza de Gen0, y cada uno de los recursos adicionales que sigan siendo necesarios los seguirá alojando en Gen0 nuevamente, y volverá a verificar si hay cosas que no se estén utilizando para eliminar el uso de esos recursos y moverá los restantes a Gen1, de esta forma hasta que todos se liberen, y hará lo mismo con Gen1 para limpiar la memoria liberando los recursos de todo aquello que ya no sea necesario marcado como Gen1 y todo lo que no pueda eliminar se ira a Gen2 y lo enviara ahí, y hará esto una y otra vez. Esto solo es una visión general de manera simplificada de como funciona el Garbage Collector (GC).

Benchmarking comparativo

Como ya vimos anteriormente podemos extraer distintas métricas sobre la eficiencia y rendimiento en ejecución de nuestro código con información adicional que nos permite comprender lo que hace la herramienta a través de un vistazo a una ejecución simplificada.

Ahora bien, el benchmarking no es solo sobre ver que tan rápido se ejecuta tu código, es útil cuando ejecutas código y empiezas a realizar comparaciones, si bien pueden estarse ejecutando en tu maquina, un código que utilizando el mismo entorno y con los mismos recursos tiene peor rendimiento, es altamente probable que vaya a suceder lo mismo en un entorno productivo. Aun así, estas pruebas puedes enviarlas a un entorno similar a producción y podrías utilizar los resultados como un buen punto de entrada para describir fenómenos relacionados al rendimiento en determinada pieza de código.

Hasta el momento hemos obtenido información pero esta es información sin contexto por lo tanto lo siguiente es, como dar contexto a nuestras comparaciones, ya que si este es un método bien escrito o no, no nos lo puede decir por su cuenta.

No podemos saber si un método es bueno o malo por si solo, no importa lo que obtengamos, para determinar si un método es bueno o no depende de los requerimientos no funcionales (atributos de calidad) establecidos para ese caso de uso o incluso nuestra aplicación y además otro método adicional que nos permita compararlos.

Para lograr este objetivo agregaremos el siguiente método a nuestra clase BenchmarkDemo y ejecutaremos la aplicación:

[Benchmark]
public string ConcatenacionConStringBuilder()
{
    var builder = new StringBuilder();

    for (int i = 0; i < 100; i++)
    {
        builder.Append(i);
    }

    return builder.ToString();

}

Cuando visualizamos las cosas por si solas, si, nos da información, obtenemos una premisa de lo que nuestro método puede estar utilizando en términos de recursos, pero esta información es vacía, sin embargo, al comparar un mismo proceso con distintas formas de hacerlo, podemos obtener una imagen completa del rendimiento y ejecución de estos, con esto podemos saber si es eficiente o no y si cumple o no con los atributos de calidad establecidos.

Linea base de ejecución

Podemos realizar comparaciones entre métodos tomando como elemento de referencia o linea base uno de los métodos agregando la propiedad Baseline con valor true al atributo Benchmark: [Benchmark(Baseline = true)]

Esto nos permite conocer el método sobre el cual vamos a comparar las métricas obtenidas de los otros métodos. La forma normal de hacer las cosas es el método marcado con esta propiedad en el atributo, comparando así las ejecuciones de los otros métodos con este, de ahí el nombre de linea base.

El ratio o proporción de 1.00 es el método considerado o marcado con Baseline a true, determinando así en los demás métodos el rendimiento proporcional a esto que este tiene, es decir, si es menos a 1.00 es mejor, y la mejora es de 1.00 menos el ratio del método en cuestión, por ejemplo, 1.00 menos 0.27 da 0.73, lo que significa que es 73% mas eficiente en términos de tiempo, etc. Cualquier cosa menor que 1.00 es mejor, y si es mayor a 1.00 entonces es peor.

Benchmarks entre distintas versiones de .NET

BenchmarkDotNet no solo nos permite comparar ejecución de métodos utilizando un solo entorno, pero además nos permite ejecutar estos métodos y compararlos entre versiones de .NET sin necesidad de crear una nueva aplicación.

Para lograr esto utilizamos el atributo SimpleJobAttribute sobre la definición de nuestra clase:

[SimpleJob(RuntimeMoniker.Net48, baseline: true)]
[SimpleJob(RuntimeMoniker.Net80)]
[MemoryDiagnoser]
public class BenchmarkDemo{}

RuntimeMoniker contiene diversos miembros que permiten indicar la versión de .NET que vamos a utilizar; RuntimeMoniker.Net48 se refiere a la versión de .NET Framework 4.8.0 y RuntimeMoniker.Net80 a .NET (.NET Core) 8.0, el argumentobaseline: true hace referencia a que la linea base o con la cual se va a comparar las ejecuciones entre frameworks es con .NET Framework 4.8.0.

Antes de ejecutar nuestra aplicación de consola para comparar entre versiones de .NET tenemos que realizar lo siguiente:

Tener instaladas cada una de las versiones de .NET que vayamos a comparar, es decir, en el caso del ejemplo, debemos tener instalado .NET Framework 4.8.0 y .NET 8.0 (.NET Core 8.0) .
Modificar el proyecto, en mi caso estoy compilando a .NET 8.0 no para .NET Framework 4.8.0 para ello podemos dar doble clic sobre el proyecto en Visual Studio o Clic Derecho > Editar Archivo del proyecto, esto abrirá el archivo .csproj del proyecto para editarlo, en caso que no uses Visual Studio solo busca dicho archivo en los archivos de la solución.
Cambiaremos la etiqueta que diga <TargetFramework>net8.0</TargetFramework> a <TargetFrameworks>net8.0;net48</TargetFrameworks> (agregando una s) separando por punto y coma cada una de las versiones a las que queramos compilar. Ten en cuenta que el valor puede ser diferente considerando las versiones que estemos utilizando.
Nos alertara de que necesita recargar algunos proyectos, le damos a recargar y luego vamos al menú Compilar > Recompilar Solucion (Build > Rebuild Solution).

Esto limpiara nuestro proyecto e inicializara y compilara todo de nuevo. Ten en cuenta que tener multiples frameworks como objetivo de compilación puede ocasionar algunos problemas de incompatibilidad entre versiones de paquetes y sintaxis del lenguaje C# que no este en versiones anteriores, por ende, utiliza estas comparativas con mucho cuidado, por ejemplo, los TLS no están disponibles en .NET Framework 4.8 ya que este es compatible con C# 7.3 y los TLS están disponibles a partir de C#9 que vino con .NET 5 significando que, nuestra clase Program debe regresar a su estructura convencional para poder ejecutar el código del benchmark:

internal class Program
{
    static void Main(string[] args)
    {
        var result = BenchmarkRunner.Run<BenchmarkDemo>();
    }
}

En términos generales puedes utilizar la compilación a múltiples versiones si te interesa dar el salto de una versión a otra de .NET Framework o .NET Core, por ejemplo, .NET 6 a .NET 8 ya que este año (2024) .NET 6 dejara de tener soporte en noviembre y quieres comparar si vale la pena hacer el salto a .NET 8 o a .NET 9 (con salida en noviembre de 2024) en términos de rendimiento si mejora o no tu aplicación e incluso si una nueva característica incorporada al lenguaje te permite mejorar el rendimiento de tu aplicación.

Utiliza con precaución esta posibilida de BenchmarkDotNet aun mas si estas comparando versiones de .NET Framework con versiones de .NET Core, por ejemplo, los usings globales, las advertencias y anotaciones nullable, entre otras características no son compatibles con versiones anteriores del lenguaje.

Algunas de estas características se deben modificar o suprimir en el archivo .csproj del proyecto, el mío luce de la siguiente forma antes de los cambios:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
        <TargetFramework>net8.0</TargetFrameworks>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="BenchmarkDotNet" Version="0.14.0" />
  </ItemGroup>

</Project>

Y ya con los cambios necesarios luce de la siguiente forma:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
        <TargetFrameworks>net8.0;net48</TargetFrameworks>
    <ImplicitUsings>disable</ImplicitUsings>
    <Nullable>disable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="BenchmarkDotNet" Version="0.14.0" />
  </ItemGroup>

</Project>

Cambiando <ImplicitUsings>enable</ImplicitUsings> a <ImplicitUsings>disable</ImplicitUsings> para desactivar los using globales implícitos y <Nullable>enable</Nullable> a <Nullable>disable</Nullable> para desactivar las anotaciones de tipos de referencia nulos en tiempo de compilación.

Si ejecutamos ahora el benchmark será el doble o el triple según la cantidad de frameworks con los que estés evaluando tus métodos y tomara mucho mas tiempo teniendo en consideración cada una de las ejecuciones además el Baseline ahora será el framework y no el método.

Y en los resultados veras las ejecuciones de cada uno de los métodos:

En la imagen anterior podemos observar una de las mayores razones para cambiar de .NET Framework a .NET Core, y es, el rendimiento de las aplicaciones en .NET Core es muy superior en términos de velocidad, administración de memoria y CPU. Obviamente existen otras razones como que .NET Core es multiplataforma, entre mas, aunque no es el objetivo principal de BenchmarkDotNet determinar esto.

Tengamos en cuenta que estamos evaluando el mismo código, los mismos métodos, ningún cambio entre plataforma, es una comparativa fiel de ambos entornos, no solo estamos comparando nuestros métodos entre si, sino que además, estamos comparando su entorno de ejecución, lo cual puede ayudarnos a tomar decisiones de manera informada respecto a nuestras aplicaciones.

Podemos comparar que incluso la versión con StringBuilder en .NET Framework tiene peor rendimiento que la versión normal en .NET Core.

De nuevo, no podemos establecer que estas métricas obtenidas van a tener ese rendimiento, eso solo ocurre tomando el hardware como un hecho, es decir, siempre y cuando el hardware sea igual o muy cercano obtendremos métricas similares, lo cual es muy difícil conseguir en un servidor de producción, pero si no es posible probarlo, lo que si es posible determinar es la evidente comparativa en el rendimiento entre métodos o incluso entre versiones de .NET, esto permite orientar no solo la decisión sobre los cambios de nuestro código sino además la toma de decisiones de diseño relacionadas al entorno de ejecución.

De esta forma podemos tomar decisiones informadas y además establecer la relación económica entre el rendimiento de la aplicación, el uso de esta y los beneficios del negocio. Si bien estamos hablando de micro o nano segundos y solo de unos cuantos kilobytes, debemos tener en cuenta que las aplicaciones no son solo utilizadas por un par de usuarios, pueden ser cientos o miles, y ahí es donde las cosas se notan en realidad.

Conclusión

Muchas veces realizamos cambios a nuestro código pensando que son cambios beneficiosos a nuestra aplicación, cambios de librerías, refactorización, abstracciones, etc, pero a lo mejor, estamos introduciendo componentes que pueden afectar directa o indirectamente el rendimiento, pero, tomando las métricas adecuadas podemos saber si nuestra implementación tiene tal valor o es mejor dejar nuestro código tal como esta, o incluso si el intercambio de rendimiento por mejorar la experiencia de de desarrollo es conveniente.

Obviamente, debemos utilizar esto con mucha precaución porque requiere trabajo adicional que no puede ser realmente justificado, por ello, evita realizar optimizaciones prematuras o incorporar flujos de trabajo que realmente no puede verse su valor en las primeras etapas de desarrollo del sistema, si llegas a identificar algo extraño una vez tu aplicación este en uso, ahí es el momento correcto para actuar.

Si estas realizando pruebas comparativas y vas a decirle a tu jefe algo respecto a los números obtenidos, recuerda no hacerlo en lenguaje técnico diciendo “Este método reduce el uso de memoria de 4kb a 1kb”, puedes decir algo como “Realizando algunos cambios en la aplicación se puede reducir el uso de memoria en 4 veces”, mientras mas destacable sea la mejora mas les puede gustar escucharte, y si puedes demostrar tus resultados en términos económicos, ten por seguro que hasta los jefes de tus jefes les encantara, especialmente si son personas mas del negocio que del área técnica.

Nota: Se cuidadoso, porque cuando haces benchmark estas ejecutando tu aplicación, tus métodos muchas veces, asegúrate de estar preparado para ello, por ejemplo, si tienes código que ejecuta operaciones hacia la base de datos, asegúrate de que esta este preparada para manejar múltiples operaciones a la vez y además de no utilizar la base de datos de producción para ello, esto mismo aplica para cualquier sistema externo a nuestra aplicación (una API, por ejemplo), además de disponer de los recursos suficientes en tu equipo. No utilices BenchmarkDotNet como un sistema de pruebas de stress, no es su propósito, utilízalo especialmente para las piezas de lógica de tu aplicación, aquellas que se ejecutan por su cuenta, no lo utilices para código que requiere interacción con la UI o sistemas con interacciones complejas.

The goal of benchmarking is to test the performance of all the methods that are frequently used (hot paths) and should be performant. The focus should be on the most common use cases, not edge cases.

Código fuente

Si el proyecto no te compila como parte de toda la solución copia el código del archivo Program.cs y pégalo en un proyecto aparte de la solución.

Recursos adicionales

https://dotnet.microsoft.com/en-us/platform/support/policy

https://github.com/dotnet/BenchmarkDotNet

https://benchmarkdotnet.org/articles/overview.html

Constructor Primario en las Clases C#

Brandon Ventura — Tue, 06 Aug 2024 20:00:39 +0000

¿Qué es un constructor?

Si bien, esto es un término que quizá la mayoría ya conozcamos, es importante definirlo para aquellos que vienen de un lenguaje de programación funcional o que no han tenido mucha cercanía con términos relacionados con la Programación Orientada a Objetos (POO), en este caso, relacionados con las clases y los objetos.

Para empezar una clase es como la plantilla o plano que nos permite definir que es lo que compone un objeto (su estructura) y aquello que este puede hacer, por ejemplo, un gato tiene un nombre, género, edad, color y puede respirar, comer, correr y dormir. Ahora bien, esto como vemos solo es describir de forma simplificada lo que todos los gatos pueden tener, pero si yo tengo un gato en específico, por ejemplo, el gato Tom, este gato en específico es un objeto, una instancia de la clase Gato, ya que tiene sus propias características o atributos que lo diferencian de otros gatos, como el nombre, género, edad, y color, a esto se le conoce como campos de la clase. Por otra parte, todos los gatos hacen de manera generalizada lo mismo, respiran, comen, corren y duermen, esto se convierte en su comportamiento, lo que en términos de clases y objetos serían los métodos de la clase. Ambas cosas, los campos y los métodos son tratados como los miembros de la clase y definen lo que se conoce como estado (información específica de cada objeto almacenado en los campos) y comportamiento (métodos que utilizan el estado para “hacer algo”).

¿No estábamos hablando de constructores? Sí, sin embargo, los constructores toman sentido cuando conocemos lo que compone una clase, esto es porque los constructores son una especie de métodos especiales que se utilizan para “construir” nuestros objetos de tal forma que permiten definir todo aquello que nuestro objeto necesita al momento de ser creado, es decir, al momento de crear una instancia de la clase.

En C# podemos tener diversos tipos de constructores como:

Constructores por defecto y sin parámetros: Es un constructor que no toma ningún parámetro y en el cual sus miembros tendrán el valor por defecto al crear el objeto. En C# todas las clases tienen un constructor por defecto que no recibe parámetros si no creamos ningún otro constructor.
Constructores con parámetros: Son constructores que reciben información a través de este para ser asignada a los campos de la clase. Son ideales cuando queremos restringir que los valores que componen el objeto deban ser adicionados al momento de crearlos.
Constructores privados: Constructores que simplemente están restringidos utilizando el modificador private, es decir, impiden que los objetos sean creados desde fuera de la clase. Esto es útil por ejemplo, para controlar la forma en que nuestros objetos se crean desde dentro de la propia clase, creando ciertas restricciones al momento de crearlos.
Constructores estáticos: Son constructores especiales que permiten asignar o inicializar datos estáticos en nuestra clase. Al ser estáticos significa que no podemos llamarlos al momento de crear nuestra instancia, sino que, el entorno de ejecución se encarga de hacerlo previamente, asignando así la información antes a la creación de nuestro objeto.
Constructores de copia: Es un tipo de constructor que en lugar de recibir los valores que vamos a asignar, recibe una instancia/objeto de la clase como argumento, permitiendo así tomar un objeto existente para extraer su información y crear un nuevo objeto a partir de este, es decir, una copia o clon. En resumen, pretenderíamos hacer esto para así tener dos objetos “iguales” (no necesariamente) para modificar uno sin perder la información que este tenía (esta se encuentra en la copia) y utilizar ambos.
Constructor primario: Lo veremos a detalle a continuación.

Cada uno de estos constructores puede tener unos cuantos detalles adicionales que vale la pena revisar, sin embargo, no vamos a definir cada uno de estos, puesto que, el objetivo de la publicación es conocer los constructores primarios, aunque, la lista puede permitirte conocer que cuando hablamos de constructores pueden existir en varios colores y sabores (al menos en C#).

public class Gato
{
    public string Nombre { get; set; }
    public string Genero { get; set; }
    public int Edad { get; set; }
    public string Color { get; set; }
    private static int _cantidadDePatas;

    // Constructor sin parametos.
    // Sí no vamos a definir otro constructor o no lo necesitamos
    // podemos borrarlo.
    public Gato()
    {

    }

    // Constructor con parametros
    public Gato(string nombre, string genero, int edad, string color)
    {
        Nombre = nombre;
        Genero = genero;
        Edad = edad;
        Color = color;
    }

    // Constructor privado
    private Gato(string nombre)
    {
        Nombre = nombre;
    }

    // Constructor estatico
    static Gato()
    {
        _cantidadDePatas = 4;
    }

    // Constructor de copia
    public Gato(Gato gato)
    {
        Nombre = gato.Nombre;
        Genero = gato.Genero;
        Edad = gato.Edad;
        Color = gato.Color;
    }

    public string ObtenerInformacionGato()
    {
        return $"El gato se llama {Nombre} tiene {Edad} años y es color {Color} y tiene {_cantidadDePatas} patas.";
    }
}

Los constructores por diseño siempre devuelven una nueva instancia de la clase, esto es importante tenerlo en cuenta, porque es su objetivo y no debemos limitar su comportamiento, si lo hacemos, estaríamos yendo en contra de lo que todos los programadores entienden por constructor de una clase introduciendo inconsistencias en nuestro código, esto es lo que permite, por ejemplo, que los constructores de copia funcionen, ya que aunque nosotros recibimos un objeto en el constructor, este siempre si o si devolverá un nuevo objeto, sea si utilizamos lo que recibimos en el constructor o no, al contrario, en un método, podríamos devolver el mismo objeto que recibimos y no nos daríamos cuenta de que se trata del mismo objeto (hasta que ocurran los errores, claro).

// Siempre sera un nuevo gato aunque sea una copia.
public Gato(Gato gato)
{
    Nombre = gato.Nombre;
    Genero = gato.Genero;
    Edad = gato.Edad;
    Color = gato.Color;
}

// No hay seguridad que obtenemos una copia real del gato.
public Gato CopiarGato()
{
    return this;
}

Constructores primarios (primary constructors)

Los constructores primarios son un tipo especial de constructor que se coloca junto a la definición del tipo, es decir, del nombre de la clase. Este tipo especial de constructor fue agregado junto con C# 9 y .NET 5 en el 2020 y se ven de la siguiente forma:

public record PersonaRecord(string Nombre, int Edad);

Aunque con los records no es muy común lo siguiente la sintaxis convencional sería:

public record PersonaRecord2
{
    public string Nombre { get; init; }
    public int Edad { get; init; }

    public PersonaRecord2(string nombre, int edad)
    {
        Nombre = nombre;
        Edad = edad;
    }
}

Si bien los records son otro tipo de dato distinto a las clases (aunque muy similares) y no vamos a entrar en detalle respecto a ellos en esta publicación, con estos llegaron los constructores primarios, y en C# 12 y .NET 8 ahora pueden ser utilizados con las clases y estructuras (struct).

Estos constructores no son más que una forma/sintaxis especial disponible en C# para definir nuestro constructor en la definición del tipo o declaración/nombre de la clase. Su sintaxis es prácticamente la misma que con los records, solo cambiando record por class:

public class Persona(string Nombre, int Edad);

El equivalente a esto en su forma convencional sería lo siguiente:

public class Persona2
{
    public string Nombre { get; set; }
    public int Edad { get; set; }

    public Persona2(string nombre, int edad)
    {
        Nombre = nombre;
        Edad = edad;
    }
}

Como puedes ver, la sintaxis de constructor primario es mucho más reducida y cómoda en cuanto a experiencia de desarrollo respecta.

¿Ambas formas son equivalente?

Si y no, en cuanto a records respecta, si lo son, debido a que el compilador se hará cargo de tomar los parámetros del constructor y generar los miembros y propiedades públicas correspondientes para los parámetros del constructor primario. Estas propiedades serán un espejo de los parámetros del constructor (nombre y tipo).

Con las clases funciona igual, ¿no?, pues no, el compilador no hará lo mismo con cualquier otra cosa que utilice un constructor primario y no sea un record, es decir, las clases y los structs no tendrán este comportamiento. En resumen:

var persona = new Persona("John Doe", 30);
// Error en tiempo de compilación, los miembros no existen en Persona.
persona.nombre;
persona.edad;

var personaRecord = new PersonaRecord("John Doe", 30);
// Los miembros son accesibles en el tipo PersonaRecord
personaRecord.Nombre;
personaRecord.Edad;

Entonces, ¿Cómo puedo acceder al nombre y edad de mi objeto creado a partir de la clase Persona? Pues, prácticamente agregando las propiedades a mano, de la siguiente forma:

public class Persona(string nombre, int edad)
{
    public string Nombre { get => nombre; set => nombre = value; }
    public int Edad { get => edad; set => edad = value; }
}
// o
public class Persona(string nombre, int edad)
{
    public string Nombre { get; set; } = nombre;
        public int Edad { get; set; } = edad;
}

Así ya tendríamos acceso nuevamente a los miembros de nuestra clase. Quizá esto te recuerda a algo, y sí, así es como se definían las propiedades antes, teniendo un campo privado el cual manipulábamos o encapsulábamos utilizando un método getter y otro setter, o como en este caso utilizando las properties de C#.

Esta no equivalencia de comportamiento entre records y clases o structs se debe a que los primary constructors en las clases/structs define sus parámetros como “privados”, lo que significa que no son accesibles desde ninguna parte fuera de la propia definición de la clase, por eso debemos crear los getters y setters correspondientes para que estos sean el acceso público al estado de nuestra clase.
Además de esto, los records en términos generales son inmutables por diseño, reforzando esto a través del propio constructor primario que define los miembros automáticamente para evitar suprimir este comportamiento, aunque siempre es posible hacerlo si definimos el record de manera convencional.

Consideraciones importantes

Hasta ahora se ha visto esta nueva sintaxis como una alternativa a la sintaxis convencional donde no parece aportar mucho, y en una comparativa muy superficial con los records parece que estos últimos son mejores, y aunque se han venido describiendo a la par hay muchas diferencias que los separan y no serán mencionadas aquí, solo se han mencionado porque los records son con los que se dio origen a esta nueva forma de definir nuestros constructores y aunque esta característica es similar para ambos, el propósito de las clases difiere del de los records, por lo tanto, hay ciertas implicaciones con el uso de constructores primarios en las clases.

Sintaxis

Aunque ya la vimos anteriormente, es bueno destacarla nuevamente y aislada de la comparativa con los records.

public class Persona(string nombre, int edad)
{
    public string Nombre { get => nombre; set => nombre = value; }
    public int Edad { get => edad; set => edad = value; }
}

Alcance, acceso y nombramiento

Lo que vemos en la definición del constructor primario no es más que los parámetros del constructor, es decir, solo es una sintaxis adicional para definir un constructor, sin embargo, puede que te preguntes ¿Cuál es el alcance de estos parámetros? ¿Cuál es su nivel de acceso?, y ¿Cuál es la convención o nomenclatura para nombrarlos?

Bueno, en realidad son solo parámetros, piensa en ellos como los parámetros del constructor convencional o los de una función o método cualquiera, la única diferencia es que los parámetros del constructor primario tienen un alcance global, es decir, pueden ser accedidos y modificados como cualquier otro parámetro, pero en este caso desde cualquier parte de la clase, estos no están limitados solo al bloque (de forma local) como en los constructores convencionales o las funciones.

Por lo tanto, podrías hacer algo como:

public class Persona(string nombre, int edad)
{
    public string Nombre { get => nombre; set => nombre = value; }
    public int Edad { get => edad; set => edad = value; }

    public void Formatear()
    {
        nombre = nombre.ToUpper(); // Modificamos el parametro no la propiedad
    }
}

Como vemos, estamos modificando el parámetro nombre asignándole un nuevo valor al ejecutar el método Formatear(), y dirás, bueno, no pasa nada, ¿no?, total si ya hemos asignado el parámetro a la propiedad Nombre, veamos lo que sucede con el siguiente código:

var nombrePersona = "John Doe";
var persona = new Persona(nombrePersona, 40);
Console.WriteLine(persona.Nombre);
Console.WriteLine($"Los nombres son iguales: {nombrePersona.Equals(persona.Nombre)}");

persona.Formatear();

Console.WriteLine(persona.Nombre);
Console.WriteLine($"Los nombres son iguales: {nombrePersona.Equals(persona.Nombre)}");

Aquí tenemos un nombre asignado a una variable y luego utilizamos esta variable para crear nuestro objeto de Persona, imprimimos el nombre y comprobamos si los nombres son iguales.

Luego ejecutamos el método Formatear() y hacemos lo mismo de nuevo, lo que veremos por consola es lo siguiente:

John Doe
Los nombres son iguales: True
JOHN DOE
Los nombres son iguales: False

Como ves, el valor ha cambiado, no hemos modificado la propiedad Nombre, sino el parámetro nombre, pero como la propiedad accede o devuelve directamente el parámetro, cualquier alteración del parámetro nombre se vera reflejada dentro de cualquier parte de la clase que acceda a él, porque este es mutable, es decir, puede cambiarse.

Respondiendo a las preguntas:

¿Cuál es el alcance de estos parámetros? El alcance es global dentro del tipo o clase, es decir, puede ser accedido desde cualquier parte de la propia clase, como cualquier parámetro lo haría dentro del constructor o función.
¿Cuál es su nivel de acceso? No es public/protected/private/internal, es solo un parámetro, su nivel de acceso está limitado a la clase, como cualquier parámetro de función que estaría limitado solo a esa función. Por este comportamiento podríamos decir que es privado, puedes verlo de esta forma si te resulta más fácil.
¿Cuál es la convención o nomenclatura para nombrarlos? Al ser parámetros, se nombran como tal, usando la nomenclatura camelCase, es decir, el nombre inicia en minúscula y cada cambio de palabra con letra mayúscula, nada de PascalCase ni con guion bajo como los campos privados (~~_nombre~~).

Inyección de dependencias

Por lo anteriormente dicho y comprobado, tenemos que tener mucho cuidado con el uso que les daremos a estos parámetros, si por ejemplo vamos a utilizarlos para la inyección de dependencias, porque hasta este momento no existe ningún tipo de restricción que pueda ser aplicada sobre estos para evitar que sean modificados dentro de la clase, por lo que, cualquier sentencia dentro de nuestra clase puede alterar su valor o contenido.


public class ServicioFalso 
{
    public string RetornaTextoMayuscula(string texto)
    {
        return texto.ToUpper();
    }
}

public class OtroServicio(ServicioFalso servicioFalso)
{

    public string ObtenerMensaje()
    {
        return servicioFalso.RetornaTextoMayuscula("Hola Mundo");
    }

    public void HacerAlgo()
    {
        servicioFalso = null;
    }
}

El código anterior expresa de manera muy simplificada una posible inyección de dependencias, como vez, el método ObtenerMensaje() llama al método RetornaTextoMayuscula() de la clase inyectada o pasada como parámetro ServicioFalso y convierte el texto a mayúscula, haciendo lo siguiente:

var servicioFalso = new ServicioFalso();
var otroServicio = new OtroServicio(servicioFalso);

var mensaje = otroServicio.ObtenerMensaje();
Console.WriteLine(mensaje);

Veríamos por consola el texto en mayúscula “HOLA MUNDO”, pero si en cambio, hacemos lo siguiente:

otroServicio.HacerAlgo();
mensaje = otroServicio.ObtenerMensaje();
Console.WriteLine(mensaje);

El programa nos lanzaría una excepción NullReferenceException, esto es debido a que cuando ejecutamos el método HacerAlgo(), este asigna el valor del parámetro servicioFalso a null, por lo que al llamar nuevamente al método ObtenerMensaje() que utiliza este parámetro, su valor será null y se lanzará la excepción.

Dicho esto, no puedes confiar en el valor que fue pasado como argumento a estos parámetros, a menos que, hayas inicializado campos o propiedades de solo lectura.

Lo ideal sería utilizar la forma convencional:


public class OtroServicio2
{
    private readonly ServicioFalso _servicioFalso;

    public OtroServicio2(ServicioFalso servicioFalso)
    {
        _servicioFalso = servicioFalso;
    }

    public string ObtenerMensaje()
    {
        return _servicioFalso.RetornaTextoMayuscula("Hola Mundo");
    }

    public void HacerAlgo()
    {
        // Error de compilación, no se puede asignar un valor a un campo de solo lectura, solo durante la inicialización
        _servicioFalso = null; 
    }
}

Pero, ¿Si la forma convencional es la correcta, para qué utilizaría un constructor primario para la inyección de dependencias? Y es que es posible encontrar un punto intermedio, donde se utilicen los constructores primarios y apliquen restricciones sobre estos valores de la siguiente forma:

public class OtroServicio3(ServicioFalso servicioFalso)
{
    private readonly ServicioFalso _servicioFalso = servicioFalso;

    public string ObtenerMensaje()
    {
        return _servicioFalso.RetornaTextoMayuscula("Hola Mundo");
    }

    public void HacerAlgo()
    {
        // Error de compilación, no se puede asignar un valor a un campo de solo lectura, solo durante la inicialización
        _servicioFalso = null;
        // Es posible al parametro pero no al campo de solo lectura
        servicioFalso = null;
    }
}

En el código anterior utilizamos los parámetros del constructor primario para asignarlos a un campo de solo lectura, de la misma forma en que lo hacemos con un constructor convencional, y dentro de la clase utilizamos este campo de solo lectura para las operaciones que necesitemos y nos olvidamos de lo que sea que haya dentro del parámetro del constructor, de esta forma aseguramos la seguridad del código y además evitamos el código repetitivo del constructor.

Esta forma sería la ideal de trabajar con los constructores primarios y la inyección de dependencias mientras no exista ningún tipo de atributo o característica dentro de C# que nos permita indicar un comportamiento distinto dentro del constructor primario.

Para la mayoría de los casos es preferible el uso del constructor convencional en las clases y structs antes que el constructor primario. En el caso de los records, el constructor primario siempre es preferido a menos que vayamos a hacer algo especial con el record.

DTOs

Si bien un buen uso para los constructores primarios en las clases puede ser en la definición de DTOs, puede ser buena idea utilizarlos si lo único necesario es mover datos a lo largo de la aplicación que no tengan ningún tipo de restricción y además, por alguna razón quieras mantener esta información mutable, que pueda cambiar en algún momento:


public class PersonaDto(string nombre, int edad)
{
    public string Nombre { get; set; } = nombre;
    public int Edad { get; set; } = edad
}

Aunque, siendo este el caso, en lo personal prefiero el uso de records, ya que estos tienen una sintaxis mucho más simplificada, y además refuerzan el diseño inmutable, haciendo que nuestros datos sean consistentes a lo largo del uso que les demos, además que nos brindan grandes características como la igualdad en los objetos, una mejor lectura en cuanto a logs respecta, entre más:

public record PersonaRecordDto(string Nombre, int Edad);

Conclusión

Con la llegada de los records a partir de C# 9 es indiscutible que estos introdujeron características y comportamientos interesantes al lenguaje, siendo la nueva sintaxis de los constructores primarios algo que llamo mucho la atención, hasta ser incorporados en C# 12 a las clases y los structs, convirtiéndose en una forma mucho más simplificada de crear los constructores y reduciendo el código repetitivo de nuestras clases en cuanto a constructores respecta, sin embargo, el mayor problema de los constructores primarios en las clases y structs es que se comportan distinto a como lo hacen en los records lo que puede ocasionar confusiones y problemas al momento de utilizarlos al no conocer como funcionan en realidad, y aunque esto puede ser resuelto de múltiples maneras como hemos visto a lo largo de esta publicación siempre es importante estar al tanto de estos detalles y muchos más que puede surgir con las nuevas características del lenguaje y mantener informados a los miembros del equipo en cuanto al uso de estas respecta.

Algunas veces más es menos y menos es más. Si es más cómodo seguir trabajando de la forma convencional, hazlo, si decides utilizar los constructores primarios ten al tanto a tus compañeros de equipo sobre esa decisión y comparte tu conocimiento con ellos para que su experiencia de desarrollo no se vea frustrada por algún problema de como estos funcionan.

Como recomendación: Utiliza los valores pasados como argumentos a los parámetros de tu constructor primario solo para la inicialización de campos y propiedades, evita utilizarlos, acceder a ellos o modificarlos en cualquier otro lugar, a menos que sea algo trivial y sin restricciones. Piensa en ellos como los parámetros de un constructor convencional, normalmente solo se usan para asignar campos y propiedades, validaciones u operaciones muy sencillas, nada más.

Además, estos son nombrados como parámetros convencionales y no pueden ser distinguidos de los parámetros utilizados dentro de las funciones/métodos de la clase lo que puede ocasionar problemas, contrario a los campos privados de la clase que por convención (regla no escrita en piedra) se les coloca el guion bajo “_” para diferenciarlos y saber donde encontrarlos. Puede parecer una tontería, pero al momento de hacer code reviews o ver el código de un proyecto que estás trabajando ayuda a aclarar dudas y facilitar la búsqueda de estos. Por cierto, si piensas que puedes nombrar los parámetros del constructor primario con guion bajo (_servicio) en realidad puedes hacerlo, pero recuerda, son parámetros no campos de la clase, en resumen, si haces algo como this._servicio para acceder a ellos no funcionara, es un parámetro no un campo o miembro de la clase.

Está claro que hay beneficios de utilizar los constructores primarios, pero no los sobreutilices o los veas como una regla escrita en piedra. Hasta que no podamos agregar restricciones o anotaciones especiales a estos parámetros, por ejemplo para limitar su mutabilidad (no podemos marcarlos como readonly, init, etc), pueden representar más un problema que una solución si no los utilizas correctamente y con cuidado.

Código fuente

Recursos adicionales

https://youtu.be/y3--fmLLmQA?si=AySAchjj3FdkjPA6

https://code-maze.com/csharp-constructors/

Operador Ternario ?: en C#

Brandon Ventura — Mon, 29 Jul 2024 16:16:20 +0000

¿Qué es el operador ternario?

El operador ternario es un operador condicional en C# como en múltiples lenguajes de programación. Si te sirve para recordarlo puedes hacer referencia al nombre de Elvis Operator, aunque este nombre es el nombre del operador de nulos en Kotlin y se aplica de forma distinta, pero a mí me sirve para recordar que debemos usar un signo de interrogación de cierre y dos puntos dentro de su sintaxis.

El semejante del Elvis Operator en C# es el Null-Coalescing Operator (??), pero este ya es otro tema.

Retomando, el operador ternario nos ayuda a definir de forma corta y/o reducida la ejecución de ciertas sentencias, asignación de valores y pequeños procesos basados en condiciones; puedes verlo como una alternativa reducida de la sentencia if-else.

Sintaxis del operador ternario

Este operador siempre debe constar de 3 operandos o elementos (de ahí su nombre):

Expresión condicional: Es la evaluación lógica que esperamos realizar (resultado de true o false).
La primera declaración: La expresión, resultado o valor que esperamos obtener si la expresión condicional da como resultado verdadero (true)
La segunda declaración: La expresión, resultado o valor que esperamos obtener si la expresión condicional da como resultado falso (false)

Viéndose de la siguiente manera: expresion_condicional ? primera_declaracion : segunda_declaracion o condicion ? consecuencia ? alternativa.

De esta forma, si expresion_condicional resulta en verdadero (true) entonces la primera_declaracion es el valor de retorno, pero, si expresion_condicional es falso (false), el operador retorna la segunda_declaracion.

Debemos tener en cuenta que el uso del operador ternario en lugar de una declaración if-else puede ayudar a tener un código más limpio, conciso y reducido, pero debemos tener cuidado de no realizar múltiples condiciones anidadas u operaciones complejas con el operador, por ello, es típicamente usado para calcular un valor o realizar una selección simple inmediata en los casos en que necesitemos realizarlo condicionalmente. Algunas veces es mucho mejor utilizar las sentencias if-else si las evaluaciones lógicas que estamos realizando son muy complejas, el operador ternario puede complicar la lectura del código y complicar el seguimiento del flujo de ejecución del programa e incluso hacer complejas futuras refactorizaciones.

Por lo tanto, podemos decir que expresion_condicional siempre será una expresión booleana.

int valor1 = 10;
int valor2 = 20;

if(valor1 > valor2)
{
    Console.WriteLine("El primer valor es mayor que el segundo.");
}
else
{
    Console.WriteLine("El segundo valor es mayor que el primero.");
}

string mensaje = valor1 > valor2 ? "El primer valor es mayor que el segundo." : "El segundo valor es mayor que el primero.";
Console.WriteLine(mensaje);

Operador ternario anidado

El operador ternario anidado (nested ternary operator en inglés), podemos utilizarlo para declarar más de una condición.

int valor1 = 10;
int valor2 = 10;

if (valor1 > valor2)
{
    Console.WriteLine("El primer valor es mayor que el segundo.");
}
else if (valor1 < valor2)
{
    Console.WriteLine("El segundo valor es mayor que el primero.");
}
else
{
    Console.WriteLine("El primer valor y el segundo son iguales.");
}

string mensaje = valor1 > valor2 ? "El primer valor es mayor que el segundo." :
    valor1 < valor2 ? "El segundo valor es mayor que el primero." : "El primer valor y el segundo son iguales.";
Console.WriteLine(mensaje);

De esta forma podemos evaluar múltiples condiciones anidando diversas expresiones que permitan obtener el valor correspondiente según el resultado de estas.

Debemos tener en cuenta que el operador ternario es asociativo por la derecha, lo que nos indica que la sentencia u ocurrencia del operador que vamos a aplicar primero es desde la derecha, es decir, la ultima expresión ternaria que se encuentre al extremo derecho. Por lo tanto, si tenemos una expresión de la forma a ? b : c ? d : e la evaluamos como a ? b : (c ? d : e) y no como (a ? b : c) ? d : e. Esto significa que el resultado de evaluar (c ? d : e) va a ser parte de la evaluación a ? b, por lo que, a ? b : resultado_c_con_d_y_e. Esto ocurre porque necesitamos conocer los resultados de cada expresión para poder determinar la siguiente evaluación que se realice en el operador ternario, si evaluamos la primera expresión no tenemos seguridad de que el valor devuelto va a ser un booleano, por lo tanto, las expresiones anidadas no podrían suceder de manera adecuada.

Expresión condicional ref

A partir de la versión 7.2 de C# podemos utilizar la palabra reservada ref para asignar una variable de referencia local de forma condicional con una expresión de referencia condicional.

var numeros = new int[] {1, 2, 3, 4, 5 };
var valor = 100;
var valor2 = valor >= 100 ? numeros[2] : numeros[4];
valor2 = 1000;
Console.WriteLine(string.Join(' ', numeros));

En el código anterior no estamos utilizando la palabra reservada ref, por lo tanto, cuando se efectúa la condición valor ≥ 100, se obtendrá el elemento en la posición 2 (tercer elemento del array, es decir, 3) o el de la posición 4 (último elemento, es decir, 5) del array, copiando así dicho valor hacia la variable valor2, por lo tanto, si cambiamos el valor de la variable valor2 a 1000, el array de numeros enteros se mantiene intacto.

Ahora realicemos lo mismo pero utilizando ref:

var numeros = new int[] { 1, 2, 3, 4, 5 };
var valor1 = 100;
ref var valor2 = ref ((valor1 >= 100) ? ref numeros[2] : ref numeros[4]);
valor2 = 10000;
Console.WriteLine(string.Join(" ", numeros));

En este caso estamos diciendo que la variable valor2 almacenara un valor como referencia, y la expresión condicional está recibiendo como resultado una referencia de un valor, a su vez las posiciones 2 y 4 del array numeros están siendo devueltas como una referencia, por lo tanto, la variable valor2 ahora no realiza una copia del valor obtenido del array sino que está apuntando mediante una referencia al tercer o último elemento del array de numeros (posición 2 y 4 respectivamente). De esta forma, si asignamos un nuevo valor a la variable valor2, lo que estamos haciendo es ir y reasignar el valor almacenado en la dirección de la referencia, como resultado, estaremos modificando el array.

Antes de C# 7.2 necesitábamos realizar algunas operaciones extra para asignar o enlazar las referencias de una variable a otra de forma condicional, de la siguiente manera:

var numeros = new int[] { 1, 2, 3, 4, 5 };
var valor = 100;
ref var valor2 = ref ObtenerPorReferencia(valor >= 100, ref numeros[2], ref numeros[4]);
valor2 = 15;
Console.WriteLine(string.Join(' ', numeros));

ref int ObtenerPorReferencia(bool condicion, ref int valorSiVerdadero, ref int valorSiFalso)
{
    if (condicion)
        return ref valorSiVerdadero;
    else
        return ref valorSiFalso;
}

Podemos observar ciertas similitudes como que la variable valor2 almacena una referencia, que el método en cuestión devuelve y que los valores obtenidos del array numeros se pasan por referencia, sin embargo, se alcanza a notar que conlleva un poco más de trabajo y además que en este caso si el array numeros es nulo o alguna de las posiciones del array es nulo, tendremos un error NRE (Null Reference Exception) porque estas expresiones se ejecutan incondicionalmente como parte del flujo del programa, situación que no ocurre con la forma ternaria debido a que las expresiones son ejecutadas según se cumpla la condición, no antes de evaluarlas.

En lo que al manejo de tipos por valor o referencia respecta, podemos tener una variable a la que se permita guardar valores por referencia a partir de una expresión condicional que retorne valores por referencia. Es decir, que en lugar de almacenar un valor (10 por ejemplo) almacenamos un “identificador, enlace, lugar, dirección” que contiene la referencia a la variable original, no el valor original, más bien, el espacio de memoria que contiene dicho valor.

Piénsalo como una caja, donde tú guardas las cosas, la caja es el espacio en memoria, o contenedor, si tú guardas un cuaderno, estás guardando el objeto, con espacio físico y tú sabes que está ahí, y luego ese cuaderno puedes llevarlo a otra caja, o colocar otro cuaderno en una caja distinta, ahora son dos cajas con cuadernos, si le quitas hojas a uno, el cuaderno de la otra caja no se ve afectado, tiene todas sus hojas.

Pero, si en lugar del cuaderno, en la primera caja guardas un papel que dice donde está el cuaderno, y luego colocas una copia de ese papel en la otra caja refiriendo al mismo cuaderno, cuando tú vayas y busques ese cuaderno en el lugar que has colocado en el papel y arranques unas cuantas hojas, si más adelante lo buscas a partir de cualquiera de los dos papeles, será el mismo cuaderno y tendrá hojas menos.

Curiosidades

El operador ternario se le conoce así porque trabaja con tres operandos. La palabra "ternario" deriva del latín "ternarius", que significa "compuesto de tres elementos".
El Elvis Operator en Kotlin en realidad es el null coalesing en C#. En Kotlin el ternary operator se consigue utilizando sentencias if-else, porque estas también pueden ser evaluadas como expresiones, por ejemplo, if (a) b else c
Python utiliza una sintaxis especial para el ternary operator: resultado if condicion else alternativa
Otros lenguajes de programación también utilizan ?: como ternario, por ejemplo JavaScript, PHP, JAVA, entre otros.

Conclusión

El operador ternario es una forma muy útil de reducir la cantidad de líneas de código, pero más aún, de introducir una forma un tanto más declarativa de expresar resultados basados en condiciones, sin embargo, su uso debe ser limitado en cuanto a la cantidad de expresiones que pretendemos evaluar así como la complejidad de estas, no hay nada que reemplace unas buenas sentencias if-else cuando las evaluaciones lógicas tienden a complicarse, y por el bien de la salud de tu código y de tus compañeros intentando descifrar los enigmas que este esconde, algunas veces es mejor utilizar la forma sencilla y convencional de realizar estas evaluaciones, ya que todos conocen la sentencia if-else, pero no todos pueden conocer el operador ternario.

Si bien el operador ternario puede variar de lenguaje en lenguaje, como ya has visto anteriormente, lo importante es conocer su existencia, así como el patrón que este sigue, luego, la sintaxis se la dejas al lenguaje en cuestión, pero tú ya sabes como funciona.

Forem: Brandon Ventura

ApiControllerAttribute en .NET Core

Antes de ApiControllerAttribute

Entonces, ¿Para que sirve el ApiControllerAttribute?

¿Cómo se utiliza?

Controladores individuales

Con una clase base

A todo el ensamblado

RouteAttribute

Validación Automática de Modelo

Invalid Model Response Customization

Source Binding Inference Rules

Client Problem Details

Conclusión

Código fuente

Recursos adicionales

Common Language Runtime (CLR) e Intermediate Language (IL)

Código Administrado y No Administrado

Código administrado

Código no administrado

¿Cuál es la Mejor Opción?

Common Language Runtime (CLR)

Funciones del CLR

Componentes del CLR

Intermediate Language (IL)

Curiosidades sobre el CLR e IL

¿La compilación JIT realizada por el CLR se ejecuta por cada método, cada vez que se llama?

¿Qué ocurre con los genéricos?

¿Cuándo se usa Reflection también se almacena en memoria el código compilado resultante mediante JIT?

Recursos adicionales

Conociendo BenchmarkDotNet

Primeros pasos

Nuestro primer Benchmark

Benchmarking comparativo

Linea base de ejecución

Benchmarks entre distintas versiones de .NET

Conclusión

Código fuente

Recursos adicionales

Constructor Primario en las Clases C#

¿Qué es un constructor?

Constructores primarios (primary constructors)

¿Ambas formas son equivalente?

Consideraciones importantes

Sintaxis

Alcance, acceso y nombramiento

Inyección de dependencias

DTOs

Conclusión

Código fuente

Recursos adicionales

Operador Ternario ?: en C#

¿Qué es el operador ternario?

Sintaxis del operador ternario

Operador ternario anidado

Expresión condicional ref

Curiosidades

Conclusión

Código fuente

Antes de `ApiControllerAttribute`

Entonces, ¿Para que sirve el `ApiControllerAttribute`?