OpenSessionInView vs PersistentContext (Extendida)

Question

Estoy trabajando en una arquitectura Hibernate/JPA/Spring/Zk, y multiplico las preguntas en estos días porque tengo que aprender mucho framework.

Tengo una pregunta que me deja perplejo durante varios días.

Escucho sobre el "patrón" OpenSessionInView para mantener viva una transacción de Hibernate para hacer una carga diferida. Muchos también dicen que el patrón no es muy limpio.

Y, por otra parte, se dice que PersistentContext extended no es seguro para subprocesos y, por lo tanto, no es adecuado para mantener vivo el entityManager.

Entonces, ¿cuál es la solución real a estos problemas? Supongo que estos problemas surgen de la introducción de ajax que permite más posibilidades, especialmente con el uso de la carga diferida para cargar algunas colecciones pesadas cuando sea necesario.

Por un momento, probé @PersistenceContext en modo extendido. Está funcionando ... Tuve que configurarlo para mis pruebas JUnit, y está funcionando también en mi aplicación web con carga diferida sin más configuraciones.

¿Es que la evolución del framework (Spring, JPA 2.0) significa que ahora es más fácil y más "limpio" trabajar con PersistentContext?

Si este no es el caso, ¿deberíamos usar OpenSessionInViewFilter desde Spring y reemplazar el PersistentContext en modo transaccional?

Gracias.

Answer 1

Te escucho. Implementé ambos patrones en varias aplicaciones desde 2008. Ahora, abandono por completo cualquier patrón de estado. Cuando introduces estado al cliente, planteas problemas de escalabilidad y administración del estado: ¿te fusionas en el cliente, guardas en la sesión de usuario, qué pasa cuando pasas por un asistente y el objeto debe ser transitorio antes de guardarlo? ¿Cómo sincronizarías el estado del cliente y del servidor? ¿Qué sucede cuando cambia db? ¿Se rompe el cliente?

Observe la tendencia de las tecnologías existentes, incluido Spring MVC: el patrón consiste en crear dos proyectos: 1) restful webservices 2) interfaces de usuario. El estado se comparte a través de un modelo de dominio inmutable. Claro que podrías terminar manteniendo un conjunto de dtos, pero son predecibles, baratos y escalan infinitamente.

Mi recomendacion? Evite enviar objetos por proxy a través del cable y trate con dtos en el cliente o comparta un modelo de dominio con el cliente si desea reutilizar validaciones en el servidor. Las colecciones perezosas se pueden cargar a través de llamadas api de grano fino a través de Ajax. De esta forma, le das control total al cliente.

Así es como ha ido escalando la red social en los últimos cinco años.