Me he estado preguntando cómo se debe manejar esta anomalía:
Pero, ¿cómo evitar una excepción JPA LazyInitialization entonces? La conversión de DTO puede necesitar datos de Lazy Fetched, pero no puede porque la capa de servicio manejó la transacción.
Se me ocurren formas, pero todas son feas. Poner la conversión DTO en la capa de servicio me parece lo mejor ahora.
Sí, definitivamente es mejor manipular los DTO en la capa de servicio. Esto es especialmente cierto cuando se actualizan entidades con cambios contenidos en DTO, ya que, de lo contrario, necesitaría obtener y actualizar entidades separadas, pasarlas al servicio, fusionarlas nuevamente en el contexto de persistencia, etc.
"Los DTO deben convertirse en el controlador, la capa de servicio no necesita conocerlos".
En lugar de esto, diría que la mejor regla general es que los controladores no necesitan saber acerca de las entidades. Pero puede usar entidades separadas en lugar de DTO para casos simples para evitar crear muchas clases pequeñas de DTO, aunque personalmente siempre uso DTO solo para ser consistente y facilitar los cambios posteriores.
La aparición de 'LazyInitializationException' es solo una señal de que algunas partes de los datos no se cargaron, por lo que la mejor solución será realizar varias llamadas desde el método del controlador al nivel de servicio y obtener todos los campos necesarios para DTO.
Las opciones menos elegantes son:
Es posible detectar campos que no se cargaron a través del método 'org.hibernate.Hibernate.isInitialized' y omitirlos durante la compilación de DTO, vea aquí la muestra completa: ¿Cómo probar si la colección JPA cargada de forma diferida está inicializada?
Puede marcar el método del controlador como transaccional, se abrirá una sesión de hibernación después de la llamada al nivel de servicio y, por lo tanto, funcionará la carga diferida.
Los DTO son el modelo contra el que debería trabajar desde una capa superior a los servicios. Solo el servicio debe conocer el modelo de entidad. En casos degenerados simples, el modelo DTO puede parecerse casi al modelo de entidad, por lo que muchas personas simplemente usarán el modelo de entidad. Esto funciona bien hasta que las personas obtienen requisitos reales que los obligarán a cambiar la forma en que usan los datos. Aquí es cuando la ilusión de que DTO = Entidad se desmorona.
Un DTO es a menudo un subconjunto o una transformación del modelo de entidad. El punto sobre LazyInitializationException es un ejemplo perfecto de cuando la ilusión comienza a desmoronarse.
Un servicio debe devolver DTO completamente inicializados, es decir, no solo un objeto que delega a objetos de entidad. No debería haber ninguna carga diferida después de que se devolviera un DTO de un servicio. Esto significa que debe obtener exactamente el estado requerido para un DTO y conectar esos datos a los objetos que se devolverán. Dado que eso generalmente requiere bastante código repetitivo y, a veces, tendrá que duplicar la lógica, las personas tienden a apegarse aún más a la ilusión DTO = Entity al rociar algunas uniones de búsqueda aquí y allá para hacer que la LazyInitializationException desaparezca.
Esta es la razón por la que inicié el proyectoBlaze-Persistence Entity Views , que le brindará lo mejor de ambos mundos. Facilidad de uso con menos repeticiones, buen rendimiento y un modelo seguro para evitar errores accidentales. ¿Quizás quieras darle una oportunidad para ver qué puede hacer por ti?