Objetos de transferencia separados del modelo

La entidad (o modelo) representa lo que se guarda: un contrato tiene socio, sede, plan, valor mensual, día de cobro, estado y fecha de fin de congelamiento. Un objeto de transferencia de datos (DTO, por sus siglas en inglés) representa lo que un caso de uso concreto acepta o devuelve: para que el socio cambie su día de cobro bastan dos campos. Separarlos tiene dos efectos: el cliente nunca enlaza contra la entidad, y cada rol tiene su propio objeto (el del socio no es el del gerente).

La guía de OWASP sobre asignación masiva pone esta separación como la primera opción, y aclara un límite: el DTO decide qué propiedades se pueden escribir, pero no reemplaza la comprobación de que esa persona puede tocar ese objeto.

Abre el laboratorio, entra en la carpeta pulsoandino-contratos y compara las tres rutas de contratos.rutas.ts. Dos crean un objeto nuevo con los campos validados y los copian uno a uno sobre el contrato. La primera declara su tipo de entrada en la firma y copia el cuerpo entero con Object.assign, que pasa al objeto destino todas las propiedades propias del origen.

Ahora busca en registro-contratos.txt qué hizo eso en la práctica.

Lee nota-revision-anterior.txt. La conclusión confunde dos cosas que en TypeScript viven en momentos distintos: lo que el compilador comprueba al escribir el código y lo que el programa hace al recibir la petición.

El valor mensual no es la única propiedad de la entidad que la ruta del socio deja escribir. Revisa en el registro qué otro cambio llegó por esa misma ruta y que en el negocio corresponde a una renovación.

Un informe útil no solo señala lo roto: también muestra lo que sí funciona, para que el equipo copie el patrón correcto. En el registro hay una petición a una ruta que copia campo a campo y que trajo un nombre de campo de más; el cambio aplicado muestra que ese campo se ignoró.