El Framework Spring 3 permite la integración con Hibernate, Java Persistence API (JPA) y Java Data Objects (JDO), para gestionar los recursos , el acceso a datos a través de implementaciones DAO, y transacciones. Un ejemplo, Hibernate, existe un API de soporte que resuelve de forma correcta la aplicación de IoC, concernientes a varios aspectos de integración con Hibernate. De ésta manera, podemos configurar todas las caracteristicas soportadas en un mapeo O/R con la caracteríscita de DI. Pueden aplicarse en la manera en la que Spring gestiona recursos y transacciones y ser compatibles con la implementación Spring 3 de trasacciones genericas y la jerarquia de excepciones para transacciones y DAOs. Para una integración con Spring 3, es recomendable implementar los DAO directamente en el API soportada, ya sea de: Hibernate, JPA o JDO. Recormamos que, en las primeras versiones de Spring 3, se aplicaba la integración a partir de "DAO templates", - no recomendado actualmente-, en la sección “Classic ORM usage” se encontrará más información acerca de esta técnica.
Se añaden mejoras significativas a la capa ORM, para las aplicaciones que acceden a la capa de recursos. Es posible, elegir el grado de integración deseado según la necesidad, para lo que debemos sopesar, el esfuerzo de integración con los costes y riesgos de "reimplementar lo existente" . Es posible reutilizar el soporte ORM como si se tratase de un componente más, ya que el diseño se basa en un conjunto de JavaBeans. ORM (ej. Hibernate) en un contenedor Spring 3 simplifica, la configuración y el despliegue.
Las ventajas de usar Spring 3 para manejar los DAO de un ORM son:
-
Facilita los test. La aproximación Spring nos permite intercambio de implementación y confugración en una instacia
SessionFactory
de Hibernate, o unDataSource
JDBC, un gestor de transacciones u otra implementación de DAO (necesario, como un DAO tipo MockObject). - Excepciones de acceso a datos genéricas. Permite aplicar "wrappers" de las excepciones propias del ORM que utilizamos, pasándolas a la jerarquia común (DataAccessException) de excepciones de java runtime. Esto nos permite manejar la mayoría de excepciones de persistencia, que suelen ser críticas, no recuperables, en las capas apropiadas, es decir que nos evita la escritura de de complicados manejadores de excepciones de acceso a datos en capas de las que no son específicas. Sin perder, la posibilidad de manejar dichas excepciones, como se desee. Recordamos que tambien las excepciones JDBC, se convierten a la misma jerarquia). Lo que nos facilita el uso de JDBC y al mismo tiempo disponer una aplicación consistente y débilmente acoplada.
-
Un manejo de recursos genérico a partir del contenedor. Los contextos Spring permitenn manejar configuración y ubicación de las instancias :
SessionFactory
de Hibernate,EntityManagerFactory
de JPA yDataSource
de JDBC y otro tipo de recursos parecidos (ej: un base de datos de fichero) y realizar cambios de forma sencilla. Por ejemplo, es posible gestionar de forma sencilla y eficiente el manejo de recursos. El código que se usa generalmente en Hibernate, a menudo necesita compartir la mísmaSession
Hibernate para asegurar eficiencia y un manejo de transacciones correcto. Spring 3 permite un manejo simple que permite recuperar y asociar laSession
aCurrentThread
de forma transparente, medianteSessionFactory Hibernate
. Así resolvemos varios problemas comunes en el uso de Hibernate clásico, para cualquier uso, ya sea de manera local o a través de JTA de las transacciones. -
Manejo Integrado de Transacciones. Podemos crear un "wrapper" Spring de nuestro código de ORM, de manera declarativa, y aplicar, declarar, aspectos (AOP) al estilo de "interceptors", ya sea a partir de anotaciones,
@Transactional,
o bien declarar explícitamente un "advice" en el fichero de configuración XML. En ambos casos, la semántica transaccional y el manejo de excepciones (ej. ejecutar "rollback", "commit",...) se manejan de manera automática. Como se discute en este artículo Rersource and transaction management, vemos que es posible intercambiar entre distintos gestores de transacciones, sin tener que modificar nuestro código ORM. Por ejemplo, intercambiar entre transacciones Local o bien a través de JTA y por tanto disponer de la mísma funcionalidad (a través de la configuración de transacciones) en ambos escenarios. De forma adicional, el código JDBC puede integrarse a nivel de transacción con el código que manejamos en el ORM. Esta integración, "facilita que sea posible el acceso a aquellos datos que no son apropiados para ser accedidos directamente a través de ORM, como por ejemplo: datos manejados en procesos batch y acceso a BLOBs en streaming. Y por tanto, compartir el mísmo espacio de transacciones.
No hay comentarios :
Publicar un comentario