Cuando usar Records en .Net
Como dije en la entrada anterior, los Records son una buena estructura de datos cuando estos han de ser inmutables, y hay muchos casos en los que necesitamos recoger una serie de datos, y realmente no necesitamos modificarlos en ningún momento más, solo usarlos.
Veamos diferentes escenarios en los que se recomienda usarlos y por qué:
- DTOs (Data Transfer Objects) ==> Los DTOs son un claro ejemplo en el que usar Records, ya que estos los usamos para transportar datos entre diferentes capas de una aplicación. Un DTO debería ser inmutable, ya que su única función es transportar esos datos y nadie debería alterarlos por el camino; una vez asignados los datos, no necesitamos modificarlos, solo acceder a ellos para su lectura o para devolverlos en un endpoint de una API, etc.
- Entidades inmutables: Lógicamente si necesitamos una clase o entidad inmutable, podremos y debemos usar Records, ya que los Records posicionales generan sus propiedades como init y son inmutables por defecto, y vamos a simplificar mucho el código y el desarrollo. Eso sí, la inmutabilidad es superficial: si una propiedad es una colección, como una List, su contenido sí se puede modificar.
- Modelos de lectura de base de datos: Los Records pueden emplearse para representar los datos que leemos de la base de datos, como proyecciones o resultados de consultas, cuando solo vamos a leerlos. No son adecuados como entidades de EF Core, ya que la igualdad basada en valores choca con el seguimiento de cambios, que se basa en la identidad de cada instancia.
- API Responses: A la hora de devolver una respuesta en una API, es ideal usar Records, ya que el valor que queremos devolver ha de ser el mismo que hemos recogido; como ya sabréis, los controladores han de tener la menor lógica posible.
- Value Objects en DDD (Domain-Driven Design): Un Value Object en DDD debe tener un valor inmutable. Si lo que deseamos es cambiar en un momento dado su valor, lo que debemos hacer es sustituirlo por una nueva instancia, por ejemplo con la expresión with. Por tanto, como un Value Object nunca se debe modificar, en este caso podremos usar Records.
- Ficheros de configuración: Cuando vamos a leer un fichero de configuración, ya sea de base de datos, de un appsettings o de donde sea, no necesitamos cambiar esos datos posteriormente para nada, por lo que necesitamos que el objeto que recoge dichos datos sea inmutable, y que nadie pueda modificarnos nada en tiempo de ejecución. Para este caso también es un buen ejemplo usar Records.
- Event Sourcing: Dentro del patrón Event Sourcing, los Records tienen la capacidad de reflejar los eventos que han tenido lugar en un sistema. La característica de inmutabilidad y la igualdad basada en valores de los Records se ajustan perfectamente a la noción de representar eventos como alteraciones de estado que no cambian.
- Logging: Cuando vamos a registrar una traza de Log, no tiene sentido estar cambiando esos valores marcados anteriormente, los valores representados han de ser los asignados en un primer momento, por lo que para este caso también es aconsejable usar Records.
- Claves de almacenamiento en caché: Al trabajar con almacenamiento en caché, los Records pueden servir como representaciones de las claves usadas para la caché, y estos valores también han de ser inmutables desde el momento en que se usan como clave. Hay que evitar que la clave contenga colecciones, ya que estas se comparan por referencia y dos claves con el mismo contenido no coincidirían. Una vez más tenemos un claro ejemplo para usar Records.
En todos estos casos que enumero y en muchos más, es una buena idea usar Records, ya que si os fijáis en todos estamos usando inmutabilidad de los datos, y no solo es que sea aconsejable, sino que la necesitamos, para asegurarnos de que los datos recogidos no los va a modificar ni alterar nadie.
En cualquier parte de nuestra aplicación que necesitemos leer datos que no vayamos a operar con ellos, ni a realizar ninguna lógica, deberíamos usar Records, y no es que sea una obligación, pero sí nos va a ahorrar mucho trabajo, ya que tienen una serie de ventajas que veremos en la siguiente entrada.
Además nos van a facilitar mucho la vida, nos van a ahorrar escribir código de primeras. Aparte vamos a ahorrarnos el tener que implementar métodos que vayamos a usar solo en los Tests (aunque esto último no es del todo cierto, ya que hay formas de evitarlo).
Espero me pongáis en comentarios en qué más situaciones se os ocurre usar Records.
¡Como siempre, gracias por leerme!