DTO se puede utilizar para transferir datos entre las diferentes capas de una aplicación: DAO, Servicio, Fachada, Controlador. En mi experiencia, DTO es un tema obstinado.

En mi opinión, cuanto más tarde sea la conversión, mejor, es incluso mejor si no se necesita conversión. Generalmente, el último está en el límite de la aplicación. DTO no es gratuito, implica mapeo y su soporte. Por lo tanto, los DTO tendrán sentido cuando haya una discrepancia del modelo de dominio o una discrepancia técnica del modelo a través del límite. Para obtener más información, puede consultar el artículo de LocalDTO y el enlace asociado .

Si me concentro en el servicio -> fachada -> capas del controlador :

• Servicios: Están haciendo cosas de servicios y pueden llamarse entre ellos para hacer su procesamiento. Si sus modelos de dominio siguen siendo coherentes en el límite de los servicios service => facade , es demasiado pronto para convertir el resultado en un DTO.

• Fachadas: Pueden orquestar servicios y convertir entrada/salida. En mi punto de vista, será el lugar adecuado para convertir hacia o desde DTO. Pero solo si es necesario, es decir. porque sus modelos de dominio deben transformarse a través de este límite (campos de filtrado, agregación...)

• Puerta de enlace/Controladores: Están en el límite de la aplicación. Sus lógicas son simples, reducidas a la lógica de los límites. La relación entre una fachada y un controlador suele ser one <-> one . ***

  La fusión de fachadas y controladores suele tener sentido

Por lo tanto, en mi punto de vista, su primera propuesta es más adecuada, por ejemplo. UserController.... . Lo más importante es ser pragmático.

Diría que es mejor crear DTO en la capa de Servicio.

El controlador no debe conocer los detalles de la lógica empresarial. Por ejemplo, necesitamos devolver la información del usuario, pero algunos campos (contraseña, etc.) deben excluirse. Los campos existen en la entidad Usuario, pero deben eliminarse de DTO.

En otro caso, obtuvimos SomePaginationDTO en el controlador y aún necesitamos pasar el DTO al servicio para analizar el filtro, aplicar la ordenación, limitar los resultados, etc. Toda la lógica es parte de la responsabilidad del servicio. Entonces pasaría SomePaginationDTO al servicio.

Yo diría que no hay una forma canónicamente correcta de hacer esto. Depende de para qué se use DTO.

Encontré una regla simple para mí sobre dónde usar DTO en el nivel de servicio y dónde no: en caso de que el nivel de servicio tenga solo un cliente, uso DTO en todo el nivel de servicio. En caso de que haya dos o más clientes, es mejor no usar DTO en el nivel de servicio.

Permítanme explicar esto con más detalles:

Básicamente, está claro que no incluir DTO en el nivel de servicio requiere más esfuerzos. Entonces, en caso de que solo haya un cliente, mantendría las cosas simples y usaría DTO como un tipo de retorno para los métodos de servicio.

En caso de que haya más de un cliente del servicio, lo más probable es que los clientes requieran un DTO diferente (por ejemplo, quiero tener una representación json y csv de un objeto). En tal caso, no devolveré a DTO del servicio. De lo contrario, necesitaría tener diferentes servicios para cada DTO, o diferentes métodos de servicio, etc.

Nota: no estoy diciendo que si no usa DTO en el nivel de servicio, debe mover la lógica de transformación al nivel del controlador. Sigo pensando que el nivel del controlador debe ser lo más simple posible. Es posible que tenga algún nivel de transformación intermedio entre el controlador y el servicio, incómodo, pero es mucho mejor que tener varios servicios.