Aplicación en capas de tres niveles que utiliza Wicket + Spring + Hibernate.¿Cómo manejarías las transacciones?

Question

Estoy pensando en usar el Sesión abierta a la vista (OSIV) filtro o interceptor que viene con Spring, ya que me parece una forma conveniente como desarrollador.Si eso es lo que recomienda, ¿recomienda usar un filtro o un interceptor y por qué?

También me pregunto cómo se combinará con Plantilla de hibernación y si perderé la capacidad de marcar métodos como @Transactional(solo lectura = verdadero) etc. y, por lo tanto, perder la capacidad de obtener un control de transacciones más detallado?

¿Existe algún tipo de práctica recomendada sobre cómo integrar este tipo de solución con una arquitectura de tres niveles usando Hibernate y Spring (ya que supongo que mi decisión de usar Wicket para la presentación no debería importar mucho)?

Si uso OSIV, al menos nunca me encontraré con excepciones de carga diferida; por otro lado, mi transacción durará más antes de poder confirmarse si también no se confirma en la vista.

Answer 1

Es realmente una cuestión de gusto personal.

En lo personal, me gusta tener límites de la transacción en la capa de servicio. Si usted comienza a pensar SOA, cada llamada a un servicio debe ser independiente. Si su capa de vista tiene que llamar 2 servicios diferentes (se podría argumentar que esto ya es un olor código), entonces esos 2 servicios deben comportarse de forma independiente el uno del otro, podría tener diferentes configuraciones de transacción, etc ... ¿Tiene han realizado operaciones ajenas abierto del servicios también ayuda a asegurarse de que ninguna modificación se produce fuera de un servicio.

otoh que tendrá que pensar un poco más sobre lo que hacen en sus servicios (carga lenta, que agrupa las funcionalidades en el mismo método de servicio si necesitan un transaccionalidad común, etc ...).

Un patrón que puede ayudar a reducir el error lazy-loading es utilizar Valor objeto fuera de la capa de servicio. Los servicios siempre deben cargar todos los datos necesarios y copiarlo en VO. Se pierde la correspondencia directa entre los objetos persistentes y su capa de vista (lo que significa que tiene que escribir más código), pero puede encontrarse con que se gana en claridad ...

Editar La decisión se basa en soluciones de compromiso, por lo que sigo pensando que es al menos en parte una cuestión de gusto personal. Transacción en la capa de servicio se siente más limpio para mí (SOA más parecido, la lógica está claramente restringido a la capa de servicios, diferentes llamadas están claramente separadas, ...). El problema con este enfoque es LazyLoadingExceptions, que se pueden resolver mediante el uso de VO. Si VO son sólo una copia de los objetos persistentes, entonces sí, es claramente una ruptura del principio DRY. Si utiliza VO como si usara una base de datos Ver, luego VO son una simplificación de ustedes objetos persistentes. Sin embargo, será más código para escribir, sino que hará que su diseño más claro. Se convierte en especialmente útil si hay que enchufar algún régimen de autorización:. Si ciertos campos son visibles sólo para ciertos papeles, puede poner la autorización en el nivel de servicio y nunca devolver los datos que no deben considerarse

Answer 2

  

Si utilizo OSIV lo haré al menos nunca se   topado con excepciones carga diferida

que no es cierto, de hecho su extremadamente fácil de ejecutar en la infame LazyInitializationException, sólo tiene que cargar un objeto, y tratar de leer un atributo de la misma, después de la vista, dependiendo de la configuración que obtendrá la LIE