Hibernar diseño de aplicaciones de carga lenta

Tiendo a usar Hibernaren combinación con Spring framework y sus capacidades de demarcación de transacciones declarativas (por ejemplo, @Transactional).

Como todos sabemos, hibernate intenta ser lo más no invasivo y lo más transparente posible, sin embargo esto demuestra un poco más desafiante al emplear lazy-loaded relaciones.

Veo una serie de alternativas de diseño con diferentes niveles de transparencia.

1. Hacer relaciones no perezosas (por ejemplo, fetchType=FetchType.EAGER)
   • Este vioalites la idea entera de la carga perezosa ..
2. Inicializar colecciones usando Hibernate.initialize(proxyObj);
   • Esto implica un acoplamiento relativamente alto al DAO
   • Aunque podemos definir una interfaz con initialize, no se garantiza que otras implementaciones proporcionen cualquier equivalente.
3. Agregar comportamiento de transacción a los objetos persistentes Model (usando proxy dinámico o @Transactional)
   • No he probado el enfoque de proxy dinámico, aunque nunca me pareció conseguir @Transactional trabajando en los propios objetos persistentes. Probablemente debido a que hibernar es la operación en un proxy para bein con.
   • Pérdida de control cuando se realizan efectivamente operaciones
4. Proporciona API perezosa / no perezosa, por ejemplo, loadData() y loadDataWithDeps()
   • Obliga a la aplicación a saber cuándo emplear qué rutina, de nuevo acoplamiento apretado
   • Method overflow, loadDataWithA(),...., loadDataWithX()
5. Forzar la búsqueda de dependencias, por ejemplo, proporcionando solo operaciones byId()
   • Requiere una gran cantidad de rutinas no orientadas a objetos, por ejemplo, findZzzById(zid), y luego getYyyIds(zid) en lugar de z.getY()
   • Puede ser útil obtener cada objeto de una colección uno por uno si hay una gran sobrecarga de procesamiento entre las transacciones.
6. Hacer parte de la aplicación @Transaccional en lugar de solo el DAO
   • Posibles consideraciones de las transacciones anidadas
   • Requiere rutinas adaptadas para la gestión de transacciones (por ejemplo, suficientemente pequeñas)
   • Pequeño impacto programático, aunque podría dar lugar a grandes transacciones
7. Proporcione al DAO perfiles dinámicos fetch , por ejemplo, loadData(id, fetchProfile);
   • Las aplicaciones deben saber qué perfil usar cuando
8. Tipo de transacciones AoP, por ejemplo, interceptar operaciones y realizar transacciones cuando sea necesario
   • Requiere manipulación de código de bytes o uso de proxy
   • Pérdida de control cuando se realizan operaciones
   • Magia negra, como siempre:)

¿Me perdí alguna opción?

¿Cuál es su enfoque preferido cuando intenta minimizar el impacto de las relaciones lazy-loaded en el diseño de su aplicación?

(Oh, y lo siento por WoT )