Hoy en día vivimos en una época donde prácticamente todas las aplicaciones tienen necesidad de intercambiar mensajes con terceros, ya sea componente que integran información con otros sistemas o servicios que disponibilizamos para que cualquiera pueda interactuar con nuestro sistema, sea cual sea el caso, tenemos la necesidad de enviar mensajes, dichos mensajes por lo general tiene un correlación directa con las Entidad de nuestra aplicación, por lo que es común utilizar dichas entidad de cómo objetos de nuestros servicios.
Una de las problemáticas más comunes cuando desarrollamos aplicaciones, es diseñar la forma en que la información debe viajar desde una capa de la aplicación a otra capa, ya que muchas veces por desconocimiento o pereza, utilizamos las clases de entidades para retornar los datos, lo que ocasiona que retornemos más datos de los necesarios, o incluso, tengamos que ir en más de una ocasión a la capa de servicios para recuperar los datos requeridos.
El patrón DTO tiene como finalidad la creación de objetos planos (POJO) con una serie de atributos que puedan ser enviados o recuperados del servidor en una sola invocación, de tal forma que un DTO puede contener información de múltiples fuentes o tablas y concentrarlas en una única clase simple.
Nuevo concepto: Entidad
Las entidades son las clases que mapean directamente contra la base de datos, es este sentido, una Entidad hace referencia a una tabla y tienen un atributo por cada columna de la tabla. Son muy utilizadas en los Frameworks ORM (Object-Relational mapping)
Para comprender mejor este patrón imaginemos que tenemos dos tablas en la base de datos, una con Clientes (Customers) y otra con su dirección (Address). La tabla Address tiene una columna que hace referencia al Cliente, pero desde el cliente no tenemos una columna para llegar a su dirección. En pocas palabras tenemos una relación “One To One”.
El problema con esta relación biene cuando queremos crear un servicio que retorne al cliente con su dirección, pues la entidad Customer no tendrá una relación al objeto Adress, lo que nos obligará a hacer dos llamadas al backend para recuperar al cliente y la dirección por separado o terminar contaminando la entidad al agregar el campo address que no es necesario para la persistencia.
Como vemos, utilizar una Entity o cualquier otro objeto que allá sido creado para otro propósito diferente que el de ser usado para transmisión de datos puede tener complicaciones, por lo que el Patrón Data Transfer Object (DTO) propone que en lugar de usar estas clases, creemos clases especiales para transmitir los datos, de esta forma, podemos controlar los datos que enviamos, el nombre, el tipo de datos, etc, además, si estos necesitan cambiar, no tiene impacto sobre la capa de servicios o datos, pues solo se utilizan para transmitir la respuesta. Dicho lo anterior, retornemos al ejemplo anterior, pero utilizando un DTO:
En este nuevo ejemplo podemos ver que hemos creado un nuevo objeto llamado CustomerDTO, en el cual podemos agregar libremente cuanto atributo requiramos, incluso, podemos asignarle valores de diferentes fuentes de datos.
Debido a que el DTO es una clase creada únicamente para una determinad respuesta, es posible modificarla sin mucho problema, pues no tiene un impacto en la capa de servicios o de datos, ya que en estas capas se trabaja con las Entidades.
Como hemos podido demostrar, DTO es un patrón muy efectivo para transmitir información entre un cliente y un servidor, pues permite crear estructuras de datos independientes de nuestro modelo de datos (Entidades), lo que nos permite crear cuantas “vistas” sean necesarias de un conjunto de tablas u orígenes de datos. Además, nos permite controlar el formato, nombre y tipos de datos con los que transmitimos los datos para ajustarnos a un determinado requerimiento. Finalmente, si por alguna razón, el modelo de datos cambio (y con ello las entidades) el cliente no se afectará, pues seguirá recibiendo el mismo DTO.
Por otro lado, analizamos como el patrón Converter es de gran ayuda para evitar la repetición de código que puede ser tedioso y propenso a errores, además, vemos que mediante la composición podemos reutilizar los convertidores para crear convertidores más avanzados.
Solo me resta mencionar un detalle importante, y es que debemos de tener cuidado que datos regresamos al cliente, ya que, por ejemplo, regresar el password de nuestros usuarios a nuestros clientes puede ser una mala idea, así que podemos omitir este campo en el converter o eliminarlo de los objetos una vez que ha sido convertido, todo dependerá de que te funcione mejor.
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:
Ver libro
© 2021, Copyright - Oscar Blancarte. All rights reserved.
