Spring Boot - DTO para cada consulta

soulsville

Buenas a todos,

estoy desarrollando un pequeño proyecto con Spring Boot para trabajar con una API Rest en el Backend pero me han surgido una serie de cuestiones de diseño a la hora de recuperar los datos de la BD (MySQL básico) mediante los repositorios JPA que no he logrado aclarar.

Mi duda principal viene motivada por la ingente cantidad de DTOs que he tenido que crear para mapear los datos de las diferentes consultas nativas, es decir, la estructura de las filas/columnas resultantes de las consultas no se ajustan a las entidades definidas por lo que me veo obligado a crear un DTO con los atributos necesarios para 'acomodar' el resultado de la consulta. De esta forma, para cada consulta que devuelva una serie de datos combinados de diferentes entidades y obtenidos de diferentes cálculos (agrupaciones, medias, etc) o simplemente un atributo inexistente en las entidades, tengo que definir un nuevo DTO.

Entiendo que hay algo que no debo estar haciendo correctamente y que deben existir alternativas para cubrir este tipo de necesidades sin que el número de objetos DTO se disparen proporcionalmente al número de consultas complejas ¿no? ¿Cuál es la mejor forma de abordar este tipo de problema?
He leído sobre la utilización de proyecciones pero sólo se aplican a una entidad -creo- para evitar recuperar datos innecesarios.

Ranthas

¿Generas tantísimos DTOs?

Actualmente estoy trabajando en una aplicación complementaria (añade funcionalidades a una aplicación de terceros) cuyo modelo de datos son unas 1200 tablas, y el módulo con el mayor número de consultas no excede 20.

Lo que yo hago es agrupar las consultas según los resultados q necesite en cada momento y genero una estructura de herencia, donde los campos comunes irían en la clase base y luego iría ramificando en función de los distintos campos que necesito en las distintas proyecciones.

Por ejemplo, si en una consulta donde participan 4 tablas (A,B,C,D), siempre guardo los IDs, campos de uso generico en el módulo, etc.

Supongo que te ves obligado a esto por el uso las "consultas nativas", pero, ¿has considerado la posibilidad de pasar de las consultas nativas y trabajar directamente con el ORM?

Yo me he visto obligado a usar las consultas nativas únicamente una vez ya que la consulta en cuestión no era abordable ni por asomo por el ORM.

Si pasas código podemos echarle un ojo más de cerca a ver q podemos hacer.

1 respuesta
JuAn4k4

Si las consultas devuelven datos que tienen sentido de negocio y los nombres de esos dtos tienen sentido para negocio. Todo en orden.

soulsville

#2 Un ejemplo podría ser el de obtener el gasto medio, pero este gasto medio debería poder venir dado por varios "filtros" o agrupaciones: gasto medio por terminal/usuario, gasto medio por sala/s, por sesión y a su vez el gasto medio detallado y combinado de cada una de esas situaciones.

Tengo una entidad Compra con un atributo importe y otros campos relacionados por clave de otras entidades (Usuario, por mencionar alguna), así que necesito realizar agrupaciones y uniones con las tablas para obtener el resultado final.
Si no te he entendido mal, lo mejor sería crear una clase común (ej: Gasto) y a partir de ahí generar otras clases que hereden de esta clase base inicial, pero de esta forma también necesitaría crear N clases con el campo/atributo que toque (sala, usuario, sesion) ¿no?

Había pensado que quizá una solución podría ser construir una clase Gasto con los campos que vaya a necesitar y posteriormente un SQLResultMapping sobre la entidad Compra para cada caso, pero de esta forma devuelvo el resto de campos existentes en esa entidad (nulos) excepto las columnas que especifique, así que no me convence mucho.

Usuarios habituales

  • soulsville
  • JuAn4k4
  • Ranthas