Conozcamos en profundidad los usos y diferencias entre estos conceptos

Es común, especialmente cuando trabajamos en proyectos grandes, ser claros a la hora de definir nuestros objetos, entender su rol y funcionalidad, sobre todo para ahorrarnos futuros dolores de cabeza. A la hora de trabajar con Clean Architectures (arquitecturas limpias) y especialmente en patrones de diseño MVC (Model-View-Controller o Modelo-Vista-Controlador) es normal y deseable separar responsabilidades y funcionalidad, desacoplar nuestras entidades y no transportar información que no se requiera. Es por eso que nace la necesidad de entender estos términos y a eso vamos!

ENTITY

Una Entity o Entidad representa justamente una entidad del dominio del negocio. Es normal, a la hora de trabajar con ORMs (Object Relational Mapping o Mapeo objeto-relacional) el uso de entidades que representen a las tablas de nuestras base de datos, como por ejemplo EntityFramework, Dapper, etc. Las entidades y sus respectivas propiedades van a representar nuestras tablas y columnas dandonos la posibilidad de trabajar con nuestros datos de manera comoda y eficiente. Pueden llegar a contener propiedades adicionales y lógica relacionada al negocio.

Por ejemplo, imaginemos una tabla llamada Student con las siguientes columnas:

Podríamos representarla como una clase Student donde cada una de sus columnas sea correspondida con una propiedad:

VIEWMODEL

Los ViewModel podríamos definirlos muy abreviadamente como "modelos para ver", no son más que clases que nos van a ser de utilidad para representar la información que necesitemos en nuestra vista. Un ViewModel podría estar compuesto por múltiples propiedades e incluso por otros ViewModels. Por ejemplo, si continuamos con el ejemplo planteado, podríamos tener un StudentViewModel el cual no posea las propiedades Id ni tampoco Document, porque no es de nuestro interés exponer este tipo de información al cliente.

Ahora bien, quizás surja la duda de ¿por qué necesito de un ViewModel si puedo simplemente utilizar mi Entity en mis vistas? Exponer directamente las entidades (o modelos de dominio) en el frontend de nuestra aplicación puede ser problemático por varias razones.

1. Separación de responsabilidades: uno de los principales estandartes de nuestras aplicaciones siempre debe ser mantener la separación de nuestro código, porque esto mejorará la claridad y la mantenibilidad del mismo. Separar la capa de acceso a datos de la capa de presentación de los mismos es muy importante.
2. Seguridad: si se exponen directamente nuestras entidades se corre el riesgo de revelar datos sensibes, utilizar ViewModels permite controlar exactamente que es lo que quiero y no quiero mostrar en mi frontend.
3. Optimizacion de los datos: al utilizar ViewModels no solo tenemos un control de lo que deseamos o no mostrar en nuestro frontend, si no que ademas podemos mejorar el rendimiento de la aplicación, especialmente en redes más lentas donde las transacciones puedan llegar a demorar varios segundos.
4. Evitar referencias innecesarias: las entidades podrían llegar a poseer relaciones complejas entre si mismas lo que sería capaz de resultar en ciclos de referencias a la hora de serializar objetos para la comunicación con el frontend, esto puede causar problemas de rendimiento y, en algunos casos errores de serialización. Los ViewModels permiten modelar la información de manera más adecuada para la presentación.
5. Adaptación a la presentación buscada: los ViewModels permiten adaptar los datos de la entidad a los requisitos específicos de la interfaz de usuario, gracias a los mismos podemos transformar datos o agregar información adicional según lo requiera.
6. Cambios independientes: al utilizar ViewModels podemos cambiar la estructura interna de las entidades sin afectar directamente la interfaz de usuario. Esto mejora la flexibilidad y permite realizar cambios en las capas internas de la aplicación sin afectar la presentación.

DTO (Data Transfer Object)

Los DTO quizás sean uno de los más confusos, me he cruzado proyectos en los cuales no siempre estan presentes justificando su uso en sistemas mucho más grandes o al contrario, su ausencia por la burocratización del código. Más allá de si decidas o no utilizarlos es importante entender su función y el por qué se decide implementarlos. Los DTO son utilizados para transferir datos entre capas de una aplicación, como por ejemplo entre la capa de servicios y la de presentación. Contiene solo los datos necesarios para la transferencia y no debe contener lógica de negocio, es decir son clases sencillas que deben ir a lo elemental de nuestro modelo de datos. Son especialmente útiles al comunicarse entre servicios web o aplicaciones cliente-servidor por lo que es frecuente verlos implementados en APIs.

Continuando con el nuestro ejemplo Student, podríamos imaginar una transacción en la que solo necesitaramos actualizar elementos que sepamos que van a verse afectados en el tiempo, como podrían serlo la edad o la ciudad.

Podemos enumerar lo siguiente:

1. Transferencia de datos eficiente: los DTOs contienen solo los datos necesarios para una operación específica, evitando la transferencia innecesaria de información.
2. Independencia de capas: los DTOs ayudan a mantener la independencia entre capas de una aplicación, por ejemplo un DTO puede definirse en la capa de servicios y luego utilizarse en la capa de presentación sin que la misma necesite conocer la estructura interna de los objetos de la capa de servicios, a si mismo los datos transportados por los DTOs podrían ser la materia prima para los ViewModels que quedarían expuestos al cliente.
3. No contiene lógica de negocio: a diferencia de las entidades, los DTOs no deben contener lógica de negocio. Su único propósito es transportar datos.

Espero haber podido aclarar un poco el uso de estos tres conceptos y puedas explotarlos al máximo en tu aplicación!