Entidades JPA y/vs DTOs

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. ¿Debe obtener/enviar entidades o DTO?
2. Servicio web llamando a los servicios. ¿Deberían los servicios aceptar entidades o DTO?

Me gusta leer el código que pasan entidades en torno a:

1. más simple para pasar alrededor, no hay necesidad de mapa de dtos
2. no necesita clases extra
3. relaciones con otras entidades ya están definidos , así que no es necesario que se combinan en una sola dtos relacionados DTO
4. solo POJOs

Pero existen argumentos sobre DTO que los mapas a una entidad son más seguros, porque es un contrato, y la entidad puede cambiar a cualquier forma, y ​​la DTO se mantendrá 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 firstName y lastName. Pero el DTO todavía tendrá un nombre de campo, que es firstName + lastName.

Así que aquí está la lista de los pros de usar DTO:

1. compatible desde el punto de código que acepta los dtos

Los contras de DTO que se me ocurre es la vista:

1. tienen que definir las clases DTO y el mapeo (tal vez usando la hoja topadora)
2. los programadores h Para analizar cuándo usar DTO y entidad, me refiero a pasar DTO por cada método es un desastre
3. gastos generales de conversión de entidades a DTO y viceversa
4. Todavía estoy inseguro sobre la relación de uno a muchos sobre cómo asignarlos En JPA podemos inicializar esto de forma lenta, pero al pasar en DTO, debería inicializar esto o no. En breve, los DTO no pueden tener proxies perezosos inicializados, solo contienen valores.

favor compartir pensamientos que ..

Gracias!

Estas son algunas citas de diferentes lugares

pro dto:

reutilización de la clase de entidad como un DTO parece desordenado. La API pública de la clase (incluidas las anotaciones en los métodos públicos ) ya no define claramente el objetivo del contrato que es presentando.La clase terminará con los métodos que solo son relevantes cuando la clase se está utilizando como DTO y algunos métodos que solo serán relavent cuando se use la clase como entidad. Las preocupaciones no serán separadas limpiamente y las cosas serán más estrechamente acopladas. Para mí eso es más importante consideración de diseño y luego intentar ahorrar en el número de archivos de clase creados.

pro entity:

Absolutamente NO !!!

Las entidades JPA se asignan a una base de datos, pero no están 'atadas' a una base de datos. Si la base de datos cambia, cambia las asignaciones, no los objetos. Los objetos siguen siendo los mismos. Ese es el punto completo !

Answer 1

Me gustaría ir a la opción DTO por las siguientes razones:

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

Answer 2

Pro DTO: 1. IU mayoría de las veces requieren determinadas propiedades que son sólo para el paso de argumentos que representan el estado de la interfaz de usuario. No se requiere que ese estado persista, por lo tanto, no se requiere su uso en las entidades.
2. La lógica de negocios debe estar dentro de las entidades o en las clases de ayuda para las entidades. No debe compartir eso con la interfaz de usuario/capa de presentación o con el cliente que lo llama.
3. El cambio en las entidades a veces no requiere un cambio en las DTO y viceversa.
4. Más fácil de realizar validaciones de nivel de sistema en DTOs en servicios de interfaz de usuario por lo tanto detener la llamada a los servicios de negocios cuando no debería.
5. Puede implementar/usar otros marcos de validación libremente cuando el lado de la interfaz de usuario recibe una DTO en lugar de la entidad que contiene los datos que provienen de la interfaz de usuario.
6. La capa de interfaz de usuario/presentación está ligeramente acoplada.

Aquí es un flujo de muestra cuando se utilizan DTO:
interfaz de usuario -> MVC -> Sistema validaciones usando la interfaz de usuario de Servicios -> Delegado de negocios -> Servicios comerciales -> Persistencia.