Trabajando con DTO
El uso de DTOs simplifica y optimiza el intercambio de datos al excluir campos innecesarios y proporcionar únicamente los datos que un cliente específico realmente necesita.
Los DTOs en este ejemplo sirven para limitar el intercambio de datos entre el cliente y el servidor. El ResponseBookDTO se utiliza para enviar solo los datos necesarios (name, author, price) al cliente, mientras que el RequestBookDTO permite a los clientes enviar los datos requeridos (date, name, author, price) al servidor.
La principal ventaja de utilizar DTOs es que ayudan a separar los datos de la lógica de negocio y permiten controlar qué datos se transfieren entre las capas de la aplicación o se incluyen en los mensajes de respuesta HTTP.
¿Dónde se aplica el DTO?
Los DTOs se utilizan cuando es necesario presentar datos en un formato específico, como para transferir datos a un cliente o recibir información de un cliente dentro del contexto de una API REST.
Esto también es relevante al interactuar entre capas en una arquitectura multicapa, donde los datos se transfieren entre servicios y repositorios.
Ejemplo de la vida real
Imagina que estás desarrollando una aplicación para una tienda en línea. Tienes una entidad llamada Product, que incluye mucha información: name, description, price, production date, discounts, y así sucesivamente.
Un cliente que solicita una lista de productos no necesita toda esta información. En su lugar, puedes crear un objeto DTO que contenga solo los campos necesarios (como el nombre y el precio) para enviar estos datos al cliente.
Ejemplo de uso
En nuestra aplicación, el modelo principal es Book, que es enviado por el cliente y devuelto por el servidor.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Sin embargo, ¿no parece que el campo id es innecesario al recibir datos del cliente, ya que se genera a nivel del repositorio? Solo necesitaremos el id al devolver una respuesta.
Aquí es donde los DTOs resultan útiles. Permiten separar la lógica y crear diferentes versiones del modelo Book para peticiones y respuestas, excluyendo campos innecesarios como id cuando corresponda.
En un DTO, se utiliza un objeto con el prefijo request para enviar datos del cliente al servidor, mientras que un objeto con el prefijo response se utiliza para enviar datos del servidor al cliente. Esta separación garantiza que solo se intercambien los datos necesarios, mejorando tanto la seguridad como la eficiencia.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Ahora tenemos dos DTOs: uno para recibir solicitudes BookRequestDTO y otro para enviar respuestas BookResponseDTO.
Se puede observar que BookResponseDTO y nuestro modelo Book son idénticos, lo que plantea la pregunta: ¿por qué crear un DTO separado si simplemente podemos usar el modelo Book?
La razón es que si posteriormente se decide agregar información adicional que solo se necesita a nivel de servicio, nuestro modelo Book terminaría pasando datos innecesarios al nivel de repositorio, lo que requeriría filtrarlos de alguna manera.
Mapper
Para transformar objetos de un tipo a otro de manera conveniente, se utiliza una biblioteca especializada.
Es posible crear una clase separada donde se definan métodos estáticos e implementar la lógica para convertir objetos entre tipos.
MapperBook.
1234567891011public class MapperBook { private static final ModelMapper mapper = new ModelMapper(); public static Book dtoRequestToModel(BookRequestDTO dto) { return mapper.map(dto, Book.class); } public static BookResponseDTO modelToResponseDto(Book book) { return mapper.map(book, BookResponseDTO.class); } }
En este código, la clase MapperBook utiliza la librería ModelMapper para la transformación automática de objetos.
Contiene dos métodos: el primero es dtoRequestToModel(), que transforma un objeto BookRequestDTO en un modelo Book utilizando el método map, y el segundo es modelToResponseDto(), que convierte un modelo Book en un objeto BookResponseDTO.
Gracias a ModelMapper, el proceso de transformación de objetos se vuelve más sencillo y práctico, eliminando la necesidad de copiar campos manualmente.
Agregar un DTO a nuestra aplicación
Resumen
DTO (Data Transfer Object) es un objeto simple diseñado para la transferencia de datos entre capas o componentes de una aplicación.
En el contexto de una arquitectura de tres capas, el DTO cumple un papel crucial al garantizar la separación de capas y proporcionar una forma eficiente de intercambiar datos entre ellas.
Por lo tanto, el uso de un DTO se convierte en una solución óptima cuando es necesario gestionar información entre diferentes partes de una aplicación, evitando la transferencia de datos innecesarios o irrelevantes.
1. ¿Qué es un DTO en el contexto de la programación?
2. ¿Cuál de las siguientes es la mejor utilización de un DTO?
¡Gracias por tus comentarios!
Pregunte a AI
Pregunte a AI
Pregunte lo que quiera o pruebe una de las preguntas sugeridas para comenzar nuestra charla
Awesome!
Completion rate improved to 3.45Trabajando con DTO
Desliza para mostrar el menú
El uso de DTOs simplifica y optimiza el intercambio de datos al excluir campos innecesarios y proporcionar únicamente los datos que un cliente específico realmente necesita.
Los DTOs en este ejemplo sirven para limitar el intercambio de datos entre el cliente y el servidor. El ResponseBookDTO se utiliza para enviar solo los datos necesarios (name, author, price) al cliente, mientras que el RequestBookDTO permite a los clientes enviar los datos requeridos (date, name, author, price) al servidor.
La principal ventaja de utilizar DTOs es que ayudan a separar los datos de la lógica de negocio y permiten controlar qué datos se transfieren entre las capas de la aplicación o se incluyen en los mensajes de respuesta HTTP.
¿Dónde se aplica el DTO?
Los DTOs se utilizan cuando es necesario presentar datos en un formato específico, como para transferir datos a un cliente o recibir información de un cliente dentro del contexto de una API REST.
Esto también es relevante al interactuar entre capas en una arquitectura multicapa, donde los datos se transfieren entre servicios y repositorios.
Ejemplo de la vida real
Imagina que estás desarrollando una aplicación para una tienda en línea. Tienes una entidad llamada Product, que incluye mucha información: name, description, price, production date, discounts, y así sucesivamente.
Un cliente que solicita una lista de productos no necesita toda esta información. En su lugar, puedes crear un objeto DTO que contenga solo los campos necesarios (como el nombre y el precio) para enviar estos datos al cliente.
Ejemplo de uso
En nuestra aplicación, el modelo principal es Book, que es enviado por el cliente y devuelto por el servidor.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Sin embargo, ¿no parece que el campo id es innecesario al recibir datos del cliente, ya que se genera a nivel del repositorio? Solo necesitaremos el id al devolver una respuesta.
Aquí es donde los DTOs resultan útiles. Permiten separar la lógica y crear diferentes versiones del modelo Book para peticiones y respuestas, excluyendo campos innecesarios como id cuando corresponda.
En un DTO, se utiliza un objeto con el prefijo request para enviar datos del cliente al servidor, mientras que un objeto con el prefijo response se utiliza para enviar datos del servidor al cliente. Esta separación garantiza que solo se intercambien los datos necesarios, mejorando tanto la seguridad como la eficiencia.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Ahora tenemos dos DTOs: uno para recibir solicitudes BookRequestDTO y otro para enviar respuestas BookResponseDTO.
Se puede observar que BookResponseDTO y nuestro modelo Book son idénticos, lo que plantea la pregunta: ¿por qué crear un DTO separado si simplemente podemos usar el modelo Book?
La razón es que si posteriormente se decide agregar información adicional que solo se necesita a nivel de servicio, nuestro modelo Book terminaría pasando datos innecesarios al nivel de repositorio, lo que requeriría filtrarlos de alguna manera.
Mapper
Para transformar objetos de un tipo a otro de manera conveniente, se utiliza una biblioteca especializada.
Es posible crear una clase separada donde se definan métodos estáticos e implementar la lógica para convertir objetos entre tipos.
MapperBook.
1234567891011public class MapperBook { private static final ModelMapper mapper = new ModelMapper(); public static Book dtoRequestToModel(BookRequestDTO dto) { return mapper.map(dto, Book.class); } public static BookResponseDTO modelToResponseDto(Book book) { return mapper.map(book, BookResponseDTO.class); } }
En este código, la clase MapperBook utiliza la librería ModelMapper para la transformación automática de objetos.
Contiene dos métodos: el primero es dtoRequestToModel(), que transforma un objeto BookRequestDTO en un modelo Book utilizando el método map, y el segundo es modelToResponseDto(), que convierte un modelo Book en un objeto BookResponseDTO.
Gracias a ModelMapper, el proceso de transformación de objetos se vuelve más sencillo y práctico, eliminando la necesidad de copiar campos manualmente.
Agregar un DTO a nuestra aplicación
Resumen
DTO (Data Transfer Object) es un objeto simple diseñado para la transferencia de datos entre capas o componentes de una aplicación.
En el contexto de una arquitectura de tres capas, el DTO cumple un papel crucial al garantizar la separación de capas y proporcionar una forma eficiente de intercambiar datos entre ellas.
Por lo tanto, el uso de un DTO se convierte en una solución óptima cuando es necesario gestionar información entre diferentes partes de una aplicación, evitando la transferencia de datos innecesarios o irrelevantes.
1. ¿Qué es un DTO en el contexto de la programación?
2. ¿Cuál de las siguientes es la mejor utilización de un DTO?
¡Gracias por tus comentarios!
