Nuestros mejores programadores agotaron sus depósitos de café, por su búsqueda día y noche por la resolución, hasta que Sebastián encontró la respuesta en Bitbucket por lo tanto ahora la compartimos contigo.
Yo votaría por el uso de DTO y este es el motivo:
- Diferentes solicitudes (eventos) y sus entidades de base de datos. A menudo sucede que sus solicitudes / respuestas son diferentes de las que tiene en el modelo de dominio. Especialmente tiene sentido en la arquitectura de microservicios, donde hay muchos eventos que provienen de otros microservicios. Por ejemplo, tiene la entidad Order, pero el evento que obtiene de otro microservicio es OrderItemAdded. Incluso si la mitad de los eventos (o solicitudes) son las mismas que las entidades, todavía tiene sentido tener un DTO para todos ellos para evitar un desorden.
- Acoplamiento entre el esquema de base de datos y la API que expone. Cuando usas entidades, básicamente expones cómo modelas tu base de datos en un microservicio en particular. En MySQL probablemente querrá que sus entidades tengan relaciones, serán bastante masivas en términos de composición. En otros tipos de bases de datos, tendría entidades planas sin muchos objetos internos. Esto significa que si usa entidades para exponer su API y desea cambiar su base de datos de, digamos, MySQL a Cassandra, también deberá cambiar su API, lo cual obviamente es algo malo.
- Contratos impulsados por el consumidor. Probablemente esto esté relacionado con la viñeta anterior, pero los DTO facilitan que se asegure de que la comunicación entre microservicios no se interrumpa durante su evolución. Debido a que los contratos y la base de datos no están acoplados, esto es más fácil de probar.
- Agregación. A veces necesita devolver más de lo que tiene en una sola entidad de base de datos. En este caso, su DTO será solo un agregador.
- Rendimiento. Los microservicios implican una gran cantidad de transferencia de datos a través de la red, lo que puede costarle problemas de rendimiento. Si los clientes de su microservicio necesitan menos datos de los que almacena en la base de datos, debe proporcionarles menos datos. Nuevamente, simplemente haga un DTO y la carga de su red disminuirá.
- Olvídese de LazyInitializationException. Los DTO no tienen ninguna carga diferida y proxy a diferencia de las entidades de dominio administradas por su ORM.
- La capa DTO no es tan difícil de soportar con las herramientas adecuadas. Por lo general, existe un problema al asignar entidades a DTO y hacia atrás: debe configurar los campos correctos manualmente cada vez que desee realizar una conversión. Es fácil olvidarse de configurar el mapeo al agregar nuevos campos a la entidad y al DTO, pero afortunadamente, hay muchas herramientas que pueden hacer esta tarea por usted. Por ejemplo, solíamos tener MapStruct en nuestro proyecto; puede generar conversiones para usted. automáticamente y en tiempo de compilación.
Las ventajas de solo exponer objetos de dominio
- Cuanto menos código escriba, menos errores producirá.
- a pesar de tener casos de prueba extensos (discutibles) en nuestra base de código, me he encontrado con errores debido a la copia incorrecta / omitida de campos del dominio a DTO o viceversa.
- Mantenibilidad – Menos código de placa de caldera.
- Si tengo que agregar un nuevo attribute, No tengo que agregar Domain, DTO, Mapper y los casos de prueba, por supuesto. No me digas que esto se puede lograr usando una utilidad beanCopy de reflexión, frustra todo el propósito.
- Lombok, Groovy, Kotlin, lo sé, pero solo me ahorrará el dolor de cabeza del setter.
- SECO
- Rendimiento
- Sé que esto entra en la categoría de “la optimización prematura del rendimiento es la raíz de todos los males”. Pero aún así, esto ahorrará algunos ciclos de CPU por no tener que crear (y luego recolectar basura) un Objeto más (como mínimo) por solicitud
Contras
- Los DTO le darán más flexibilidad a largo plazo
- Si tan solo alguna vez necesitara esa flexibilidad. Al menos, lo que sea que encontré hasta ahora son operaciones CRUD a través de http que puedo administrar usando un par de @JsonIgnores. O si hay uno o dos campos que necesitan una transformación que no se puede hacer usando Jackson Annotation, como dije antes, puedo escribir lógica personalizada para manejar eso.
- Los objetos de dominio se llenan de anotaciones.
- Esta es una preocupación valida. Si utilizo JPA o MyBatis como mi marco persistente, el objeto de dominio podría tener esas anotaciones, entonces también habrá anotaciones de Jackson. Sin embargo, en mi caso, esto no es muy aplicable, estoy usando Spring boot y puedo escapar usando propiedades de toda la aplicación como
mybatis.configuration.map-underscore-to-camel-case: true,spring.jackson.property-naming-strategy: SNAKE_CASE
- Esta es una preocupación valida. Si utilizo JPA o MyBatis como mi marco persistente, el objeto de dominio podría tener esas anotaciones, entonces también habrá anotaciones de Jackson. Sin embargo, en mi caso, esto no es muy aplicable, estoy usando Spring boot y puedo escapar usando propiedades de toda la aplicación como
Cuento, al menos en mi caso, los contras no superan a los pros, por lo que no tiene ningún sentido repetirme teniendo un nuevo POJO como DTO. Menos código, menos posibilidades de errores. Por lo tanto, continúe con la exposición del objeto de dominio y no tenga un objeto de “vista” separado.
Descargo de responsabilidad: Esto puede ser aplicable o no en su caso de uso. Esta observación es según mi caso de uso (básicamente una API CRUD que tiene puntos finales 15ish)
La decisión es mucho más sencilla en caso de que utilice CQRS porque:
- para el lado de escritura que usas
Commandsque ya son DTO;Aggregates– los objetos de comportamiento enriquecido en su capa de dominio – no están expuestos / consultados, por lo que no hay ningún problema allí. - para el lado de lectura, debido a que usa una capa delgada, los objetos extraídos de la persistencia ya deberían ser DTO. No debería haber ningún problema de mapeo porque puede tener un
readmodelpara cada caso de uso. En el peor de los casos, puede usar algo como GraphQL para seleccionar solo los campos que necesita.
Si no divide la lectura de la escritura, la decisión es más difícil porque hay compensaciones en ambas soluciones.
Comentarios y puntuaciones del artículo
Eres capaz de añadir valor a nuestro contenido cooperando tu veteranía en las interpretaciones.
¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)