La mayoría de las veces cuando desarrollamos aplicativos (si estos no son muy simples) utilizamos capas para separar las funcionalidades y desacoplar los módulos entre sí. Esto nos da agilidad, modularidad y nos permite estructurar nuestro código conforme a los estándares y realizar pruebas con mayor facilidad.
Uno de los problemas más comunes del desarrollo de aplicaciones es determinar como enviamos y los datos entre nuestras capas. Lo más sencillo es enviar la información bruta, lo cual no quiere decir que sea la mejor idea, ya que esta información sin tratar es en su gran mayoría inútil (las capas no usan todos los datos).
Además, sabemos que normalmente nuestras entidades necesitan de otras para funcionar, un tipo de dato enumerado, una categoría, etc.
Para resolver esta problemática surge un patrón de diseño de comunicación entre capas llamado Data Transfer Objects (DTO).
Este patrón consiste en crear objetos planos que contienen toda la información necesaria para que la aplicación realice su cometido. Cuando digo toda la información necesaria digo que tiene SOLO la información necesaria. Además, al invocar un tiempo de objeto DTO se consigue transportar toda la información con una sola llamada.
Los objetos DTO no proveen lógica de aplicación ni validaciones, como el nombre indica se usan para transferir datos compuestos de manera eficiente y concisa.
Imaginar la situación de una APP que necesita presentar en la capa de presentación los datos de un empleadoy su departamento, y cuantos compañeros mas están en este.
Tendríamos que consultar el empleado, nuevamente consultar el departamento de este y realizar una consulta para saber cuantos compañeros tiene.
Si utilizamos simplemente las entidades, la vista debe realizar varias consultas, el patrón DTO utiliza un mapeado que devuelve un objeto DTO con toda la información necesaria para que la vista haga su función, todo esto con una sola llamada.
Las herramientas de AutoMapper por ejemplo en Asp.net nos ayudan a este cometido.
¿Usar DTO o Entidades?
Esta pregunta nos va a surgir en la mayoría de casos cuando trabajamos con bases de datos. La respuesta está en la función de cada elemento, las entidades han sido creadas para mapear los datos con la base de datos, mientras que los DTO están pensados para presentar datos (ya se a una vista o en una API).
Por tanto, debemos ser conscientes de utilizar los elementos con una finalidad, esto evita que tengamos que crear nuevos campos en una entidad para satisfacer las necesidades de una vista (una mala práctica frecuente), que hace poco legible nuestro código y vulnera el principio de responsabilidad única.
