En el desenvolupament de programari modern, especialment quan parlem d'aplicacions distribuïdes, microserveis o integracions amb serveis cloud, un dels elements més repetits són els DTOs (Data Transfer Objects). Durant anys, la pràctica estàndard en C# ha estat definir-los com a classes amb propietats públiques i setters mutables. No obstant això, l'evolució del llenguatge ens ha portat els records, una eina que canvia les regles del joc per als qui busquen qualitat, seguretat i mantenibilitat en els seus projectes. En Q2BSTUDIO, com a empresa especialitzada en aplicacions a mida, hem vist de primera mà com aquesta decisió tècnica impacta en l'estabilitat de sistemes crítics.
Un DTO, per definició, és un contracte de dades. Representa una fotografia d'informació en un moment concret: el payload d'una sol·licitud, la resposta d'una API, un esdeveniment en una cua de missatgeria. Si ho penses bé, aquesta fotografia no hauria de canviar després de ser capturada. No obstant això, les classes tradicionals amb get; set; permeten que qualsevol part del codi modifiqui aquest estat, cosa que obre la porta a errors difícils de rastrejar. En sectors com la banca o les fintech, on treballem amb transaccions i dades sensibles, una mutació accidental es pot traduir en duplicitat de pagaments, auditories corruptes o fallades en la conciliació. Per això, cada vegada més equips d'enginyeria opten per records, una característica nativa de C# que promou la immutabilitat i la igualtat per valor.
El principal avantatge dels records és que eliminen l'ambigüitat: quan declares un record, el compilador genera automàticament propietats de només inicialització (init-only), un mètode ToString útil per a logs, deconstrucció i, el més important, una implementació correcta d'Equals i GetHashCode basada en el valor dels seus camps. Això significa que dos registres amb les mateixes dades es consideren iguals, una cosa que amb classes requeriria escriure i mantenir codi manual propens a errors. En un projecte de programari a mida, on els requisits canvien i els equips creixen, delegar aquesta responsabilitat al compilador redueix dràsticament el deute tècnic.
Imaginem un pipeline d'ingesta d'esdeveniments per a un sistema d'intel·ligència artificial. Un agent IA pot necessitar processar milers de notificacions per segon. Si aquestes notificacions són objectes mutables, cada etapa del pipeline podria alterar l'estat original, trencant la idempotència i generant dades inconsistents per a l'entrenament de models. Amb records, en canvi, cada transformació produeix una nova instància, preservant el fet original. Aquesta propietat és essencial quan construïm serveis cloud AWS i Azure que han d'escalar horitzontalment sense estats compartits.
Una altra àrea on els records brillen és en la integració amb eines d'intel·ligència de negoci. Per exemple, en generar reports amb Power BI des de dades emmagatzemades a Azure, els DTOs que representen files de conciliació es beneficien de la igualtat per valor per realitzar operacions de conjunt com Except, Intersect o Distinct sense necessitat d'implementar comparadors personalitzats. Això simplifica el codi i millora la llegibilitat, una cosa vital quan oferim serveis intel·ligència de negoci a clients que necessiten dashboards precisos i actualitzats.
Per suposat, no tot és perfecte. Els records tenen limitacions que tothom ha de conèixer. Per exemple, no són adequats per a entitats d'ORM com Entity Framework Core, on la identitat i el cicle de vida són clau. Tampoc gestionen ben col·leccions mutables: si un record conté una llista, la igualtat per valor es trenca perquè List<T> compara per referència. En aquests casos, recomanem usar ImmutableArray o replantejar el disseny. En Q2BSTUDIO, quan desenvolupem aplicacions a mida, avaluem cada context per decidir entre records, classes o estructures, sempre pensant en la mantenibilitat a llarg termini.
La ciberseguretat també es beneficia de la immutabilitat. Un DTO immutable no pot ser modificat per un atacant que hagi compromès un middleware intermedi, ja que l'objecte queda segellat després de la seva creació. Això redueix la superfície d'atac en integracions amb tercers. A més, en arquitectures de microserveis amb cues com Kafka, on els esdeveniments es reenvien i reprocessen, la garantia que el missatge original no ha estat alterat és fonamental per a la consistència. El nostre equip integra pràctiques de ciberseguretat i pentesting en cada fase del desenvolupament, i els records són una capa defensiva simple però efectiva.
Des del punt de vista del rendiment, els records no són més ràpids que les classes, però permeten eliminar codi defensiu costós: còpies defensives, bloquejos de concurrència, comparacions basades en serialització JSON, etc. En pipelins d'alt throughput, aquesta eliminació es tradueix en menor latència i menor pressió sobre el recol·lector d'escombraries. Per a casos extrems, com cotitzacions de Forex o ticks de preus, podem fer servir readonly record struct, que s'allotja a la pila i genera zero pressió de GC.
En Q2BSTUDIO apliquem aquests principis en cada projecte. Per exemple, en un sistema d'automatització de processos per a una empresa logística,gramem els DTOs d'esdeveniments de classes a records i reduïm els bugs de duplicació en un 80%. També fem servir records per modelar comandaments i consultes en una arquitectura CQRS basada en MediatR, cosa que va facilitar la implementació d'agents IA que orquestren fluxos d'aprovació.
Si el teu equip encara fa servir classes mutables per a tots els DTOs, et convidem a reconsiderar. La transició es pot fer gradualment, començant per nous contractes a la frontera del sistema. El benefici en qualitat, claredat i reducció de bugs és immediat. I si necessites ajuda per modernitzar la teva plataforma, en Q2BSTUDIO oferim consultoria i desenvolupament especialitzat en ia per a empreses, serveis cloud AWS i Azure, Power BI i integració de sistemes. Contàctans i descobreix com podem transformar la teva arquitectura de dades.
