Dudas sobre uso de DTOs y prácticas de arquitectura en el proyecto Screenmatch

Hola Jose, espero que estés bien

¡Gracias por compartir tus dudas! Vamos a desglosar tus preguntas una por una para intentar aclarar tus inquietudes sobre el uso de DTOs y las prácticas de arquitectura en el proyecto Screenmatch.

1. ¿Por qué no se explica con más profundidad qué es un DTO y por qué no conviene exponer directamente las entidades JPA en una API REST?

   Un DTO (Data Transfer Object) es un patrón de diseño utilizado para transferir datos entre diferentes partes de un programa, especialmente entre capas de una aplicación. La razón principal para no exponer directamente las entidades JPA en una API REST es la seguridad y la encapsulación de datos. Las entidades JPA suelen contener más información de la necesaria para el cliente, y exponerlas directamente podría revelar detalles internos de la aplicación o permitir modificaciones no deseadas. Además, los DTOs pueden ayudar a reducir el acoplamiento entre las capas de la aplicación.

2. ¿No sería mejor práctica separar esta lógica de transformación en una clase Mapper para mantener el principio de responsabilidad única? ¿O incluso utilizar una herramienta como ModelMapper o MapStruct?

   Separar la lógica de transformación en una clase Mapper es, de hecho, una buena práctica, ya que ayuda a adherirse al principio de responsabilidad única. Esto hace que el código sea más limpio y fácil de mantener. Herramientas como ModelMapper o MapStruct pueden automatizar este proceso, reduciendo el código repetitivo y minimizando errores. Estas herramientas son especialmente útiles en aplicaciones más grandes donde el mapeo manual puede volverse tedioso.

3. ¿Por qué se eligió record para representar el DTO? ¿Es solo por concisión o porque es inmutable? ¿Cuáles serían sus limitaciones si en el futuro el DTO tuviera lógica adicional?

   Se eligió usar record en Java principalmente por su concisión y porque son inmutables por defecto, lo que puede mejorar la seguridad del hilo y la integridad de los datos. Sin embargo, los records están diseñados para ser simples contenedores de datos, y si en el futuro necesitas añadir lógica adicional o métodos complejos, podrías encontrar limitaciones. En tales casos, podrías considerar cambiar a una clase tradicional.

4. ¿Se considera buena práctica hacer toda la lógica de mapeo a DTO directamente dentro del controlador en aplicaciones más grandes?

   En aplicaciones más grandes, no es recomendable realizar toda la lógica de mapeo directamente en el controlador. Esto puede llevar a controladores demasiado cargados y difíciles de mantener. Es mejor delegar esta responsabilidad a clases específicas, como Mappers o Servicios, para mantener un código más limpio y modular.

Espero que estas explicaciones te ayuden a comprender mejor las decisiones tomadas en el proyecto y cómo aplicarlas a tus propios desarrollos. ¡Espero haber ayudado y buenos estudios!