Spring MVC: ¿Debería la capa de servicio regresar a los DTO específicos de operación?

Question

En mi aplicación Spring MVC estoy usando DTO en la capa de presentación para encapsular el modelo de dominio en la capa de servicio. Los DTO se usan como objetos de respaldo de forma de resorte.

por lo tanto, mis servicios ser algo como esto:

userService.storeUser(NewUserRequestDTO req); 

La capa de servicio se traducirá DTO -> objeto Dominio y haga el resto del trabajo.

Ahora mi problema es que cuando quiero recuperar un DTO del servicio para realizar, por ejemplo, una Actualización o una Pantalla, parece que no puedo encontrar una mejor manera de hacerlo que tener múltiples métodos para la búsqueda que devuelven diferentes DTO es como ...

EditUserRequestDTO userService.loadUserForEdit(int id); 

DisplayUserDTO userService.loadUserForDisplay(int id); 

pero algo no se siente bien acerca de este enfoque. Quizás el servicio no debería devolver cosas como EditUserRequestDTO y el controlador debería ser responsable de ensamblar un requestDTO desde un objeto de formulario dedicado y viceversa. El motivo por el que DTO es diferente es que DisplayUserDTO está fuertemente tipeado para ser de solo lectura y también hay muchas propiedades del usuario que son entidades de una tabla de búsqueda en el DB (como ciudad y estado) para que DisplayUserDTO tenga el descripción de cadena de las propiedades, mientras que EditUserRequestDTO tendrá los identificadores que respaldarán las listas desplegables de selección en los formularios.

¿Qué opinas?

gracias

Answer 1

me gustan los objetos de visualización se desnudaron. Es más eficiente que crear todo el objeto de dominio solo para mostrar algunos campos de él. He usado un patrón similar con una diferencia. En lugar de usar una versión de edición de un DTO, acabo de usar el objeto de dominio en la vista. Redujo significativamente el trabajo de copiar datos entre los objetos. No he decidido si quiero hacer eso ahora, ya que estoy usando las anotaciones para JPA y el Marco de Validación de Bean y mezclar las anotaciones parece desordenado. Pero no me gusta usar DTO con el único propósito de mantener objetos de dominio fuera de la capa MVC. Parece mucho trabajo por poco beneficio. Además, podría ser útil leer la toma de Fowler en anemic objects. Es posible que no se aplique exactamente, pero vale la pena pensar en ello.

---

1st Edit: responda el siguiente comentario.

Sí, me gusta usar los objetos de dominio reales para todas las páginas que operan en un solo objeto a la vez: editar, ver, crear, etc

Dijiste que está tomando un objeto y la copia existente los campos que necesita en un DTO y luego pasar el DTO como parte del modelo a su motor de plantillas para una página de visualización (o viceversa para una creación). ¿Qué te compra eso? La referencia al DTO no pesa menos que la referencia al objeto de dominio completo, y usted tiene que hacer todo el copiado de atributos adicionales. No hay una regla que diga que su motor de plantillas tiene que usar todos los métodos en su objeto.

Usaría un pequeño objeto de dominio parcial si mejora la eficacia (no hay gráficos de relación para compilar), especialmente para los resultados de una búsqueda. Pero si el objeto ya existe, no se preocupe por lo grande o complejo que es cuando lo pegue en el modelo para representar una página. No mueve el objeto en la memoria. No causa el estrés del motor de plantillas. Simplemente accede a los métodos que necesita e ignora el resto.

---

2da edición: Buen punto. Hay situaciones en las que desearía que un conjunto limitado de propiedades estuviera disponible para la vista (es decir, diferentes desarrolladores de aplicaciones para el usuario y servicios de fondo). Debo leer más cuidadosamente antes de responder. Si fuera a hacer lo que deseaba, probablemente pondría métodos separados en Usuario (o en cualquier clase) del formulario para Editar() y para Mostrar(). De esta forma, puede obtener al usuario de la capa de servicio y decirle al usuario que le proporcione el uso de copias limitadas de sí mismo. Creo que tal vez eso es lo que estaba buscando con el comentario de los objetos anémicos.

Answer 2

¡Debe usar un DTO y nunca un ORM en la capa de MVC! Hay una serie de preguntas realmente buenas ya formuladas sobre esto, como las siguientes: Why should I isolate my domain entities from my presentation layer?

Pero para agregar a esa pregunta, debe separarlas para ayudar a evitar que el ORM se vincule a una publicación ya que el potencial está ahí para alguien para agregar un campo adicional y causar todo tipo de caos que requiera una validación adicional innecesaria.