Una de las novedades más destacables de .NET 9 es, sin duda, el nuevo sistema de caché híbrida (Hybrid cache), una puesta al día del sistema de caché distribuida que nos acompaña desde las primeras versiones de .NET Core, y al que iban haciendo falta ya algunas mejoras.

Este nuevo sistema está construido encima de la infraestructura de caching existente (Microsoft.Extensions.Caching), añadiendo mejoras que hacen que su uso sea más sencillo y contemplando de serie funcionalidades que antes nos veíamos obligados a implementar manualmente.

Vamos a echarle un vistazo a sus principales características :)

Disclaimer: lo que vamos a ver a continuación está basado en .NET 9 RC2, por lo que todavía es posible que haya cambios en la versión final.

¿Qué aporta Hybrid Cache sobre IDistributedCache?

Empecemos por la que, para mi gusto, es la principal aportación de Hybrid Cache: la protección contra estampidas.

Una estampida es el efecto que puede ocurrir en sistemas que usan caché para soportar una carga muy alta de peticiones al mismo tiempo. En ellos, si la caché se invalida por algún motivo, todas las peticiones concurrentes que llegan mientras ésta no haya sido poblada de nuevo intentarán recargarla simultáneamente, dando lugar a un ataque masivo al servidor de origen que en el peor de los casos puede llevarlo al suelo.

Con la protección integrada contra estampidas, Hybrid Cache se encarga de gestionar las peticiones concurrentes, permitiendo que sólo una de ellas llegue al servidor de origen y el resto esperen a que la caché sea repoblada. Esto es una funcionalidad que antes debíamos implementar manualmente, y no siempre era trivial hacerlo bien.

Otra característica realmente interesante de Hybrid Cache es la implementación de serie de una caché multinivel, solucionando un escenario que es bastante frecuente en sistemas distribuidos: aunque usemos un mecanismo externo como Redis, Memcached u otros, es muy habitual que también tengamos una caché en memoria en el propio servidor, para evitar tener que ir a la caché externa en cada petición.

Hybrid Cache nos permite configurar fácilmente una caché de nivel 1 (L1) en memoria del servidor (usando la clase MemoryCache de siempre), y una caché de nivel 2 (L2) en un sistema externo (usando IDistributedCache), y gestionar la sincronización entre ambas de forma transparente. Es decir, desde nuestro código simplemente escribiremos o leeremos a través de Hybrid Cache, y éste se encargará de gestionar la comunicación con la caché en memoria y la externa.

Por otra parte, como recordaréis, IDisbributedCache es una interfaz muy simple que sólo nos permite almacenar y recuperar bytes, por lo que si queríamos almacenar contenidos más sofisticados como objetos o estructuras, teníamos que encargarnos de serializarlos y deserializarlos manualmente, dando lugar a mucho código repetitivo, propenso a errores, y muchas veces poco eficiente.

Hybrid Cache ha mejorado las APIs para interactuar con la caché, con el objetivo de simplificar su uso en los escenarios más frecuentes. Los métodos para almacenar y recuperar datos de la caché son más fáciles de usar, y permiten el uso directo de objetos complejos sin necesidad de serializarlos o deserializarlos manualmente.

Por defecto, Hybrid Cache serializará sin problema las secuencias de bytes (digamos que es el formato nativo), las cadenas de texto serán convertidas a bytes UTF-8, y el resto de tipos de datos se usará System.Text.Json para obtener su representación JSON, aunque si fuera necesario, podemos configurar serializadores personalizados para tipos de datos específicos. En todo caso, el payload puede ser comprimido para ahorrar espacio y minimizar los datos en circulación.

También es interesante destacar la introducción de la invalidación basada en tags, un mecanismo que permite agrupar elementos de la caché bajo una misma etiqueta, y luego invalidar todos los elementos que tengan esa etiqueta de forma sencilla. Hasta ahora, la única forma de conseguir algo parecido era implementar manualmente algún mecanismo de agrupación externo a la caché y eliminar las entradas una a una.

La reutilización de objetos permite mejorar el rendimiento en escenarios donde los objetos almacenados en la caché distribuida son grandes o se accede a ellos con mucha frecuencia. Cuando estos objetos sean inmutables y su estado no sea alterado desde el código, es posible que Hybrid Cache pueda reutilizar el objeto entre distintas peticiones concurrentes en lugar de deserializarlo de nuevo cada vez.

Uso de Hybrid Cache

La clase abstracta HybridCache, definida en el espacio de nombres Microsoft.Extensions.Caching.Distributed es la que nos dará acceso a las funcionalidades de la caché híbrida. Internamente existe una implementación concreta de esta clase llamada DefaultHybridCache, que es la que usaremos en la mayoría de los casos, aunque será transparente para nosotros porque normalmente trabajaremos con la clase abstracta.

De momento, estos nuevos tipos no vienen incluidos en los metapaquetes básicos de .NET 9, sino que se distribuye a través del paquete NuGet independiente Microsoft.Extensions.Caching.Hybrid, que es necesario instalar en los proyectos donde queramos usarlos. A día de hoy, todavía son paquetes en preview, pero en pocas semanas serán ya definitivos.

Una vez instalado, lo habitual será registrar el servicio en el contenedor de dependencias de la aplicación, para lo que usaremos el método AddHybridCache de la clase IServiceCollection. Luego, podemos reclamar instancias de HybridCache donde deseemos usar sus servicios.

Por ejemplo, la siguiente aplicación ASP.NET Core registra HybridCache y luego lo usa desde un endpoint para almacenar y recuperar la hora actual, pero actualizándose solo cada 5 segundos:

var builder = WebApplication.CreateBuilder(args);

// Agregamos los servicios de caché híbrida
builder.Services.AddHybridCache();

var app = builder.Build();

app.MapGet("/", async (HybridCache cache) =>
{
    DateTime cachedItem = await cache.GetOrCreateAsync(
        key: "currentTime",
        factory: _ => ValueTask.FromResult(DateTime.Now),
        options: new HybridCacheEntryOptions()
                {
                    LocalCacheExpiration = TimeSpan.FromSeconds(5),
                }
        );
    return cachedItem;
});

app.Run();

Pero fijaos que en el ejemplo anterior sólo estamos usando la caché de primer nivel, porque no hemos configurado la caché distribuida o de segundo nivel. Para ello, necesitamos registrar un servicio IDistributedCache en el contenedor de dependencias; HybridCache detectará automáticamente la presencia de este servicio y usará la caché de segundo nivel.

Por ejemplo, si queremos usar Redis como caché distribuida, podemos instalar el paquete NuGet Microsoft.Extensions.Caching.StackExchangeRedis y registrar el servicio de IDistributedCache en el contenedor de dependencias de forma similar a la siguiente:

var builder = WebApplication.CreateBuilder(args);

// Agregamos los servicios de caché híbrida
builder.Services.AddHybridCache();

// Agregamos los servicios de caché distribuida con Redis
builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("RedisConnectionString");
    options.InstanceName = "HybridCacheDemo";
});

var app = builder.Build();

app.MapGet("/", async (HybridCache cache) =>
{
    DateTime cachedItem = await cache.GetOrCreateAsync(
        key: "CurrentTime",
        factory: _ => ValueTask.FromResult(DateTime.Now),
        options: new HybridCacheEntryOptions()
                {
                    // Establecemos la expiración de caché local y distribuida:
                    LocalCacheExpiration = TimeSpan.FromSeconds(5),
                    Expiration = TimeSpan.FromSeconds(10)
                }
    );
    return cachedItem;
});

Obviamente, HybridCache es mucho más que lo que hemos visto aquí, pero creo que estos ejemplos son suficientes para hacernos una idea de cómo se configura y se usa. Si queréis profundizar más, os recomiendo que le echéis un vistazo a la documentación oficial de .NET 9.

¡Espero que os haya resultado interesante!

Publicado en Variable not found.

Probablemente, todos hemos usado en algún momento el método Guid.NewGuid() de .NET para generar identificadores únicos globales. Y muchos hemos sufrido con el problema que supone su (pseudo) aleatoriedad, principalmente cuando necesitamos ordenarlos... sobre todo si su destino final es acabar siendo el campo clave de una base de datos relacional.

Pero pocos éramos conscientes de que el método Guid.NewGuid() de .NET retorna un GUID versión 4, y que existen otras versiones de UUID (¡hasta 8!) que pueden resultar más beneficiosas en determinados escenarios.

Como sabemos, una forma habitual de registrar servicios en el contenedor de dependencias de .NET consiste en indicar al framework la implementación de la interfaz o clase abstracta que debe ser utilizada cuando se solicite una instancia de la misma. Por ejemplo, en el siguiente código, que podría pertenecer a la inicialización de una aplicación ASP.NET Core, se registra la implementación FriendDbRepository para la interfaz IFriendRepository con un ámbito scoped o por petición:

builder.Services.AddScoped<IFriendRepository, FriendDbRepository>();

Hecho esto, podríamos solicitar una instancia de IFriendRepository en cualquier parte de nuestra aplicación que admita inyección de dependencias, como los controladores, manejadores Minimal API, otras dependencias, etc. El inyector encargará de proporcionarnos una instancia de FriendDbRepository allá donde la necesitemos:

public class FriendsController: Controller
{
    public FriendsController(IFriendRepository friendRepository)
    {
        // ... Aquí la tenemos!
    }
}

O bien, podríamos obtenerla directamente desde la colección de servicios:

public void DoSomething(IServiceProvider services)
{
    var repo = services.GetRequiredService<IFriendRepository>();
    ...
}

Como vemos en ambos casos, la única forma disponible para identificar el servicio que deseamos obtener es utilizar su tipo, o muy habitualmente, la abstracción (interfaz o clase abstracta) a la que está asociado.

Pero eso cambió con la llegada de .NET 8...

Cuando trabajamos con diccionarios en .NET, es muy común comprobar si existe un elemento con una clave determinada antes de obtenerlo para evitar una excepción KeyNotFoundException:

var numbers = new Dictionary<int, string>()
{
    [1] = "One",
    [2] = "Two",
    [3] = "Three"
};

// Aseguramos que el elemento existe antes de obtenerlo
if (numbers.ContainsKey(3))
{
    Console.WriteLine(numbers[3]);
}

Sin embargo, esta comprobación tiene coste. Es decir, aunque el acceso a los diccionarios sea muy rápido -O(1)-, no quiere decir que no consuma tiempo, por lo que es interesante conocer alternativas más eficientes para estos escenarios.

Hace poco vimos cómo serializar y deserializar datos en JSON de forma personalizada usando custom converters e implementamos un ejemplo simple capaz de introducir en campos de tipo int de .NET casi cualquier valor que pudiera venir en un JSON.

Pero como comentamos en su momento, la serialización y deserialización de objetos más complejos no es una tarea tan sencilla y requiere algo más de esfuerzo. En este post vamos a ver la solución para un escenario que creo que puede ser relativamente habitual: deserializar un objeto JSON a un diccionario Dictionary<string, object>.

En otras palabras, queremos que funcione algo como el siguiente código:

using static System.Console;
...
var json = """
{
    "name": "Juan",
    "age": 30
}
""";

var dict = ... // Código de deserialización
WriteLine($"{dict["name"]} tiene {dict["age"]} años"); // --> Juan tiene 30 años

Hace poco, andaba enfrascado en el proceso de modernización de una aplicación antigua que, entre otras cosas, guardaba datos en formato JSON en un repositorio de archivos. Dado que se trataba de una aplicación creada con .NET "clásico", la serialización y deserialización de estos datos se realizaba utilizando la popular biblioteca Newtonsoft.Json.

Al pasar a versiones modernas de .NET, esta biblioteca ya no es la mejor opción, pues ya el propio framework nos facilita las herramientas necesarias para realizar estas tareas de forma más eficiente mediante los componentes del espacio de nombres System.Text.Json. Y aquí es donde empiezan a explotar las cosas 😉.

Si habéis trabajado con este tipo de asuntos, probablemente habréis notado que, por defecto, los componentes de deserialización creados por James Newton-King son bastante permisivos y dejan pasar cosas que System.Text.Json no permite. Por ejemplo, si tenemos una clase .NET con una propiedad de tipo string y queremos deserializar un valor JSON numérico sobre ella, Newtonsoft.Json lo hará sin problemas, pero System.Text.Json nos lanzará una excepción. Esa laxitud de Newtonsoft.Json es algo que en ocasiones nos puede venir bien, pero en otras puede puede hacer pasar por alto errores en nuestros datos que luego, al ser procesados por componentes de deserialización distintos, podrían ocasionar problemas.

Por ejemplo, observad el siguiente código:

var json = """
           {
              "Count": "1234"
           }
           """;

// Deserializamos usando Newtonsoft.Json:
var nsj = Newtonsoft.Json.JsonConvert.DeserializeObject<Data>(json);
Console.WriteLine("Newtonsoft: " + nsj.Count);

// Intentamos deserializar usando System.Text.Json
// y se lanzará una excepción:
var stj = System.Text.Json.JsonSerializer.Deserialize<Data>(json);
Console.WriteLine("System.Text.Json: " + stj.Count);
Console.Read();

// La clase de datos utilizada
record Data(int Count);

Para casos como este, nos vendrá bien conocer qué son los custom converters y cómo podemos utilizarlos.

Sabemos que está feo y no sea especialmente recomendable en muchos casos, pero hay veces en las que es totalmente necesario acceder a miembros privados de una clase. Por ejemplo, sería un requisito  imprescindible si fuéramos a implementar un serializador o deserializador personalizado, o necesitásemos clonar objetos, o simplemente realizar pruebas unitarias a una clase que no ha sido diseñada para ello.

Para conseguirlo, siempre hemos utilizado los mecanismos de introspección de .NET, conocidos por todos como reflexión o por su término en inglés reflection. Por ejemplo, imaginemos una clase como la siguiente, virtualmente inexpugnable:

public class BlackBox
{
    private string _message = "This is a private message";
    private void ShowMessage(string msg) => Console.WriteLine(msg);
    public override string ToString() => _message;
}

Aunque a priori no podemos hacer nada con ella desde fuera, usando reflexión podríamos acceder sin problema a sus miembros privados, ya sean propiedades, campos, métodos o cualquier tipo de elemento, como podemos ver en el siguiente ejemplo:

var instance = new BlackBox();

// Obtenemos el valor del campo privado _message:
var field = typeof(BlackBox)
    .GetField("_message", BindingFlags.NonPublic | BindingFlags.Instance);
var value = field!.GetValue(instance);

// Ahora llamamos al método privado ShowMessage():
var method = typeof(BlackBox)
    .GetMethod("ShowMessage", BindingFlags.NonPublic | BindingFlags.Instance);
method.Invoke(instance, [value]);

// Al ejecutar, se nuestra en consola: "This is a private message"

Sin embargo, de todos es sabido que la reflexión es un mecanismo muy lento, a veces farragoso en su implementación y, sobre todo, incompatible con tree-shaking, que es como se suele llamar la técnica que usan los compiladores de eliminar del código final todas las clases, métodos y propiedades que no se utilizan en el código final. Esta técnica va tomando cada vez más relevancia conforme los compiladores son capaces de crear directamente ejecutables nativos puros, porque permiten reducir de forma considerable el peso de los artefactos creados.

Por esta razón, en .NET 8 se ha incluido una nueva fórmula para acceder a miembros privados, mucho más eficiente y amistosa con AOT, porque se lleva a tiempo de compilación algo que antes obligatoriamente se resolvía en tiempo de ejecución.

Seguro que más de una vez habéis tenido que construir una abstracción sobre DateTime para poder controlar apropiadamente la obtención de la fecha/hora actual y otras operaciones relacionadas con el tiempo.

Suelen ser bastante útiles cuando creamos pruebas unitarias de métodos que dependan del momento actual. Por ejemplo, ¿cómo testearíamos de forma automática que las dos líneas de ejecución del siguiente método DoSomething() funcionan correctamente? Sería imposible salvo que ejecutásemos las pruebas a una hora determinada, algo que se antoja complicado 😉

public class MyClass
{
    public string DoSomething()
    {
        var now = DateTime.Now;
        return now.Second == 0
            ? "A new minute is starting"
            : "Current second " + now.Second;
    }
}  

Sin duda, una forma mejor y más test friendly sería contar con una abstracción sobre el proveedor de tiempos capaz de retornar la fecha y hora actual, por ejemplo:

public interface IDateTimeProvider
{
    DateTime GetCurrentDateTime();
}

De esta forma, podríamos reescribir la clase MyClass de forma que recibiera por inyección de dependencias nuestro proveedor IDateTimeProvider. Así sería realmente sencillo crear un par de pruebas unitarias que, suministrando los valores correctos a través de esta dependencia, podrían recrear los escenarios a cubrir:

public class MyClass
{
    private readonly IDateTimeServices _dateTimeServices;
    public TimeHelpers(IDateTimeServices dateTimeServices)
    {
        _dateTimeServices = dateTimeServices;
    }
    public string DoSomething()
    {
        var now = _dateTimeServices.GetCurrentDateTime();
        return now.Second == 0
            ? "A new minute is starting"
            : "Current second " + now.Second;
    }
}  

Aunque hacerlo de esta manera en nuestras aplicaciones es lo ideal, hay partes que se quedarían fuera de esta posibilidad, como las bibliotecas de terceros que de alguna forma dependan de las funcionalidades proporcionadas por DateTime.

Por esta razón, .NET 8 va a introducir una abstracción que nos permitirá gestionar estos escenarios de forma más homogénea y generalizada en aplicaciones y componentes .NET. 

Os presento la clase abstracta TimeProvider 😁

Seguro que habéis visto más de una vez un código parecido al siguiente, en el que llamamos a una API  REST externa y su resultado es deserializado a un objeto .NET para introducirlo en el flujo de la aplicación:

async Task<User[]> GetUsersAsync()
{
    var httpClient = _httpClientFactory.CreateClient();
    
    // Hacemos la llamada
    var response = await httpClient.GetAsync("https://jsonplaceholder.typicode.com/users");

    // Si la cosa no fue bien, retornamos
    if (!response.IsSuccessStatusCode)
        return Array.Empty<User>();

    // Descargamos la respuesta y la deserializamos
    var usersAsJson = await response.Content.ReadAsStringAsync();
    var users = JsonSerializer.Deserialize<User[]>(usersAsJson);

    return users;
}

Fijaos que el JSON de la respuesta de la API lo guardamos en una cadena de caracteres para, justo después, deserializarlo y convertirlo en un array de objetos User. Que levante la mano el que no lo haya hecho nunca 😉

¿Y veis dónde está el problema? A la salida de este método, tendremos en memoria dos copias de los datos de los usuarios, una en forma de string JSON y otra en el objeto que hemos deserializado.

Si estamos hablando de respuestas pequeñas o con poca concurrencia, probablemente el impacto es inapreciable. Pero si las estructuras retornadas por la API tuvieran un tamaño considerable o estamos en un escenario de múltiples llamadas simultáneas, esta duplicidad sería un auténtico derroche de recursos.

Hace unos días hablábamos de la serialización polimórfica en .NET 6, y vimos qué posibilidades teníamos para conseguirlo sin tener que escribir un custom converter o conversor personalizado. Y aunque realmente .NET 6 permite hacerlo, no es lo más elegante del mundo porque teníamos que operar sobre tipos object.

Pero por suerte, en .NET 7 la cosa ha mejorado y ya tenemos opciones razonables para conseguirlo basadas en los dos nuevos atributos [JsonDerivedType] y [JsonPolymorphic]. Veamos cómo utilizarlos.

Imaginad una clase como la siguiente, que representa las características básicas de los archivos almacenados en una aplicación:

public class File
{
    public string FileName { get; set; }
    public ulong SizeBytes { get; set; }
}

Y ahora, imaginemos también una clase que hereda de la anterior para modelar específicamente, aunque también de forma resumida, los archivos de vídeo:

public class VideoFile: File
{
    public string Codec { get; set; }
    public TimeSpan Duration { get; set; }
}

Y puestos a imaginar, acabemos con el siguiente método, que retorna la representación JSON del objeto File que recibe como parámetro:

string SerializeFile(File file) => JsonSerializer.Serialize(file);

Gracias al polimorfismo, ese pilar imprescindible de la Programación Orientada a Objetos, podríamos invocar este método con objetos de tipo File, VideoFile o cualquier descendiente de alguno de ambos, puesto que en todos los casos se trata de objetos de tipo File:

var file = new File 
{ 
    FileName = "file.txt", SizeBytes = 1024 
};
Console.WriteLine(SerializeFile(file));

var videoFile = new VideoFile 
{ 
    FileName = "video.mp4", 
    SizeBytes = 1024 * 1024, 
    Codec = "H264", 
    Duration = TimeSpan.FromMinutes(3)
};
Console.WriteLine(SerializeFile(videoFile));

A raíz del artículo publicado hace algunas semanas sobre las ventajas de usar diccionarios en lugar de listas, me llegaba vía comentarios un escenario en el que se utilizaba una clase List<T> para almacenar objetos a los que luego se accedía mediante clave. Lo diferencial del caso es que dichos objetos tenían varias claves únicas a través de las cuales podían ser localizados.

Por verlo por un ejemplo, el caso era más o menos como el que sigue:

public class FriendsCollection
{
    private List<Friend> _friends = new();
    ...
    public void Add(Friend friend)
    {
        _friends.Add(friend);
    }

    public Friend? GetById(int id) 
        => _friends.FirstOrDefault(f => f.Id == id);

    public Friend? GetByToken(string token) 
        => _friends.FirstOrDefault(f => f.Token == token);
}

Obviamente en este escenario no podemos sustituir alegremente la lista por un diccionario, porque necesitamos acceder a los elementos usando dos claves distintas. Pero, por supuesto, podemos conseguir también la ansiada búsqueda O(1) si le echamos muy poquito más de tiempo.

A veces, los problemas de rendimiento de las aplicaciones, o determinadas funcionalidades de ellas, vienen derivados del uso de estructuras incorrectas para almacenar los datos, ya sea en memoria, base de datos o en cualquier tipo de almacén.

En este post vamos a centrarnos en un caso específico que me he encontrado demasiadas veces en código real: el uso indebido del tipo List<T> cuando sólo nos interesa buscar en esta colección por una propiedad que actúa como identificador único del objeto T.

Seguimos hablando de problemas que es habitual solucionarlos de una determinada manera, quizás por costumbre, quizás por pereza, o tal vez por desconocimiento de que haya otras formas de hacerlo. En este caso, hablaremos de una necesidad que probablemente habréis tenido alguna vez: transformar un GUID a una cadena de caracteres eliminando los habituales guiones.

Es decir, dado un GUID con el valor 1f5772a6-91ca-4035-8b6d-9676ec6d0eaa, queremos obtener su representación como cadena de caracteres, pero eliminando los guiones, resultando "1f5772a691ca40358b6d9676ec6d0eaa".

En código que veo, incluso escrito por mí un tiempo atrás, es muy habitual encontrar comparaciones de cadenas de caracteres en las que, para asegurar que el casing no sea tenido en cuenta, se fuerza una conversión de alguno de los operandos, o incluso ambos, a mayúsculas o minúsculas.

En escenarios muy simples esto funcionará bien y no tendrá contraindicaciones especialmente graves para nuestro sistema. Veamos unos ejemplos:

// Ejemplo 1: conversión de un único operando
int Calculate(string op, int a, int b)
{
    // Pasamos a minúsculas el operador para
    // asegurar que encaja con la constante
    if(op.ToLower()=="add")
    {
        return a+b;
    } 
    else if(op.ToLower()=="sub")
    {
        return a-b;
    }
    ...
}

// Ejemplo  2: conversión de ambos operandos
bool AreBrothers(User user1, User user2)
{
    // Pasamos a mayúsculas ambos apellidos por
    // si alguno se ha escrito usando otro casing
    var areBrothers = user1.Surname.ToUpper() == user2.Surname.ToUpper();
    return areBrothers;
}

Sin embargo, aunque pueda parecer despreciable, estas operaciones de transformación a mayúsculas o minúsculas tienen un coste importante, que se pone especialmente de manifiesto cuando estamos hablando de aplicaciones con mucha carga de usuarios, alojada en infraestructura muy ajustada o cuando se requiere un rendimiento extremo.

En un vídeo del canal de Nick Chapsas, al que por cierto os recomiendo suscribiros, he descubierto que .NET 7 introducirá un mecanismo para "decorar" parámetros, propiedades y miembros de tipo string de forma que podamos aportar información sobre el tipo de contenido que esperan almacenar.

Para que lo entendáis mejor, observad el siguiente ejemplo, una función que recibe un mensaje y un formato de fecha, y que escribe por consola la fecha actual en el formato indicado seguido del mensaje.

void Log(string message, string dateFormat)
{
    Console.WriteLine(DateTime.UtcNow.ToString(dateFormat) + " - " + message);
}

Log("Hello!", "dd/MM/yyyy hh:mm");

Desde el punto de vista del consumidor de la función Log(), gracias a las ayudas del IDE podremos deducir que el segundo parámetro de tipo string, llamado dateFormat, debería ser un formato de fecha válido en .NET. Sin embargo, el entorno de desarrollo no podrá ofrecer ningún tipo de ayuda a la hora de codificar la llamada ni detectar si se producen errores, pues no dispone de información suficiente sobre el tipo de contenido esperado en la cadena de texto que se le suministra.

De casualidad me he topado con un interesante cambio que .NET 5 introdujo en los componentes de serialización y deserialización System.Text.Json y que, al menos para mí, pasó totalmente desapercibido en su momento. Por eso, he pensado que quizás sea buena idea dejarlo por aquí, por si hay algún despistado más al que pueda resultar útil.

Como seguro sabéis, al usar los componentes de System.Text.Json para serializar o deserializar una clase, utilizamos el atributo [JsonIgnore] para marcar las propiedades que queremos que sean ignoradas al convertir desde y hacia JSON.

Por ejemplo, dada la siguiente clase:

class User
{
    public int Id { get; set; }
    public string Email { get; set; }
    [JsonIgnore]
    public string Token { get; set; }
}

En ella estamos indicando expresamente que la propiedad Token debe ser ignorada, por lo que ésta no aparecerá si serializamos un objeto a JSON:

var user = new User { Id = 42, Email = "john@server.com", Token = "ABCDEF"};
Console.WriteLine(JsonSerializer.Serialize(user));

// Result:
{"Id":42,"Email":"john@server.com"}

Y lo mismo ocurre en sentido contrario:

var jsonStr = "{ \"Id\": 42, \"Email\": \"john@server.com\", \"Token\": \"ABCDEF\"}";
var user = JsonSerializer.Deserialize<User>(jsonStr);
// ¡user.Token es nulo aquí!

A veces, desde aplicaciones .NET de consola, escritorio, o incluso ASP.NET Core, puede resultar interesante conectarse con una hoja de Google Sheets para añadir filas de datos.

Hay varias formas de conseguirlo, pero aquí vamos a ver la que creo que es la más sencilla, pues permite evitar parte del engorroso workflow de OAuth y, lo que es mejor, podemos usarla sin necesitar credenciales de usuario desde, por ejemplo, un servidor o un proceso desasistido.

Ojo: las APIs de Google que vamos a ver son gratuitas, pero tienen limitaciones de uso que debéis conocer antes de utilizarlas.

A grandes rasgos, el proceso consta de los siguientes pasos, que seguiremos a lo largo del post:

• Configuración del proyecto y credenciales en Google Developer Console.
• Creación del documento Google Sheet en el que añadiremos las filas.
• Consumo de las APIs de Google para añadir datos.

¡A por ello!

Solemos pensar que el punto de entrada de una aplicación .NET, ya sea el método estático Main() del clásico Program.cs o el nuevo Program.cs de .NET 6 que utiliza top level statements, es lo primero que se ejecuta en nuestras aplicaciones, en realidad no es así. Hay vida antes de que nuestra aplicación empiece a correr ;)

Aunque obviamente su utilidad es limitada y no es algo que necesitaremos hacer a menudo (o probablemente nunca), es conveniente saber que existen varias formas de insertar código que se ejecute antes que lo que siempre hemos considerado el entry point de nuestra aplicación, y es lo que veremos en este post.

La semana pasada veíamos algunas alternativas para comprobar de forma eficiente si una cadena de texto contiene un JSON válido y, al hilo de dicho post, el amigo Javier Campos aportó vía Twitter una fórmula adicional mejor que las que vimos aquí.

El código en cuestión es el siguiente:

public bool IsJsonWithReader(string maybeJson)
{
    try
    {
        var reader = new Utf8JsonReader(Encoding.UTF8.GetBytes(maybeJson));
        reader.Read();
        reader.Skip();
        return true;
    }
    catch
    {
        return false;
    }
}

La estructura Utf8JsonReader ofrece una API de alto rendimiento para acceder en modo forward-only y read-only al JSON presente en una secuencia de bytes UTF8. Los métodos Read() y Skip() se encargan respectivamente de leer el primer token del JSON y saltarse todos sus hijos, con lo que en la práctica se recorrerá el documento completo, lanzándose una excepción en caso de ser inválido.