jsf - example - Entidades JPA y/vs DTOs

spring boot dto to entity

Question

¿Cuál es la idea general para ayudar a decidir cuándo usar DTO y cuándo usar Entity en estos casos?

1. UI / server side java llamando a los servicios. ¿Debería obtener / enviar entidades o DTOs?
2. Servicio web llamando a los servicios. ¿Deberían los servicios aceptar entidades o DTOs?

Me gusta leer el código que pasa alrededor de las entidades:

1. más fácil de pasar, no es necesario asignar a DTOs
2. no necesito clases extras
3. las relaciones con otras entidades ya están definidas, por lo que no es necesario combinar las DTO relacionadas en una DTO
4. solo POJOs

Pero hay argumentos sobre el DTO que los mapas a una entidad son más seguros, porque es un contrato, y la entidad puede cambiar a cualquier forma, y ​​el DTO seguirá igual. Por ejemplo, al igual que la entidad tiene un nombre de campo, y el DTO también tiene un nombre de campo. Más adelante, si el requisito cambia, la tabla de la base de datos cambia, la entidad también puede cambiar, cambiando el nombre a nombre y apellido. Pero el DTO todavía tendrá un nombre de campo, que es el primer nombre + apellido.

Así que aquí está la lista de las ventajas de usar DTOs:

1. Compatible con versiones anteriores desde el punto de vista del código que acepta los DTO

Los contras de DTO que puedo pensar es:

1. tiene que definir las clases DTO y la asignación (tal vez utilizando dozer)
2. los programadores tendrían que analizar cuándo usar DTO y entidad, me refiero a que pasar DTO para cada método es un desastre
3. Gastos generales de conversión de entidades a DTO y viceversa.
4. Todavía no estoy seguro acerca de la relación de uno a muchos sobre cómo mapearlos. En JPA podemos inicializarlo de forma perezosa, pero cuando se pasa DTO, debo inicializar esto o no. En breve, los DTO no pueden tener proxies inicializados perezosos, solo contienen valores.

Por favor comparte tus pensamientos ..

Gracias !

Aquí hay algunas citas de diferentes lugares.

pro dto :

La reutilización de la clase de entidad como DTO parece desordenada. La API pública de la clase (incluidas las anotaciones sobre métodos públicos) ya no define claramente el propósito del contrato que está presentando. La clase terminará con métodos que solo son relevantes cuando la clase se usa como DTO y algunos métodos que solo serán relevantes cuando la clase se usa como una entidad. Las preocupaciones no se separarán limpiamente y las cosas se unirán más estrechamente. Para mí, esa es una consideración de diseño más importante que intentar ahorrar en la cantidad de archivos de clase creados.

entidad pro :

¡¡¡Absolutamente no!!!

Las entidades JPA se asignan a una base de datos, pero no están "vinculadas" a una base de datos. Si la base de datos cambia, usted cambia las asignaciones, no los objetos. Los objetos permanecen igual. ¡Ese es todo el punto!

Answer 1

Iría por la opción DTO por las siguientes razones:

• La interfaz de servicio debe ser independiente de la base de datos, un cambio en uno no siempre debe requerir un cambio en el otro.
• Está asumiendo que sus servicios siempre serán llamados por un cliente Java
• El uso de la carga diferida cuando el objeto está en el otro lado de una llamada de servicio web no funciona bien.

Answer 2

Pro DTO: 1. La mayoría de las veces, la interfaz de usuario requiere ciertas propiedades que son solo para pasar argumentos que representan el estado de la interfaz de usuario. No se requiere que ese estado persista, por lo tanto, no se requiere que se use en las entidades.
2. La lógica de negocios debe estar dentro de entidades o en clases auxiliares para entidades. No debe compartirlo con la IU / Capa de presentación ni con que el Cliente lo llame.
3. El cambio en las entidades a veces no requiere un cambio en los DTO y viceversa.
4. Es más fácil realizar validaciones a nivel del sistema en DTO en servicios de UI, por lo que se detiene la llamada a los servicios empresariales cuando no debería.
5. Puede implementar / usar otros marcos de validación libremente cuando el lado de la IU esté recibiendo un DTO en lugar de una entidad con los datos provenientes de la IU.
6. La capa de UI / Presentación está acoplada de manera holgada.

Aquí hay un flujo de muestra cuando se usan DTOs:
UI -> MVC -> Validaciones del sistema usando Servicios UI -> Business Delegate -> Business Services -> Persist.