Definir modelo propio para capa de servicio

[acuevas-dgtic]

Definir modelo propio para capa de servicio, independiente del modelo mapeado en JPA (actualmente en módulo persistence). El modelo mapeado en JPA sería mejor que quedase interno en la capa de negocio, sin visibilidad en la capa web. Este enfoque tiene como desventaja tener que trasladar datos entre modelo JPA y modelo de negocio, pero queda la capa de negocio mucho mejor definida y evita los problemas de navegación entre objetos JPA (errores inicialización lazy) . Hay librerías que facilitan esta traslado de datos (p. ej.: mapstruct)

[antonireus]

S'ha afegit un component projectebase-service per la capa indicada a #80, i dins el package es.caib.projectebase.service.model s'inclouen els DTO que es fan servir tant a la capa web com a la capa REST.

Dins la capa EJB es realitza la conversió entity <-> dto emprant l'eina MapStruct.

Coses a comentar:

• Totes les capes (web/REST/JPA) empraven les anotacions de BeanValidation definides a l'Entity. Ara aquestes anotacions s'han traslladat als DTO, per tant no estan als Entity. Per garantir que no s'envien objectes invàlids a la capa de serveis s'empren la validació de BeanValidation a la invocació dels mètodes de la capa de serveis. Però dins un mètode intern de la capa de serveis es podria potencialment fixar un valor que no complís aquestes regles. Una alternativa seria duplicar les anotacions de validació dels DTO als Entity.
• Tot i que en general la capa de persistència retorna i reb Entity, i la capa de serveis fa la conversió amb MapStruct (realment funciona molt bé), en el cas de llistats, per temes d'eficiència, s'empren consultes de projecció -hi ha exemples amb JPQL i amb Criteria-, que ja retorna objectes DTO. emprant el constructor.

[antonireus]

Al final he optat per duplicar les anotacions de validació. Les que estan als entity garanteixen la validesa del que s'envia a BDD, mentre que les que estan als dto serveixen de cara a la capa de presentació.