Master J2EE de Oracle: Paso 9 de 12: Persistencia y POJOs: La Unión de los Mundos de Objetos y Relac

Puede encontrar la versión original de este artículo en Inglés en:

http://www.oracle.com/technology/pub/articles/masterj2ee/index.html

La combinación de Oracle TopLink y la capa DAO de Spring ofrece una aproximación productiva y de alto rendimiento a la persistencia de Objetos Java Normales (Plain Old Java Objects POJOs)

Persistencia y POJOs: La Unión de los Mundos de Objetos y Relacional

Toda aplicación J2EE necesita acceder a una (o más) bases de datos relacionales, por eso no es pretencioso decir que una de las decisiones más importantes que hará usted cuando seleccione la arquitectura de una aplicación J2EE es cómo accederá la aplicación a los datos persistentes: Su estrategia de persistencia no sólo puede determinar el rendimiento de la apliación, sino que también influirá enormemente en la cantidad de esfuerzo requerido para desarrollar y mantener la aplicación; y a menos que tome las decisiones de diseño correctas desde el principio, podría ser difícil revisar esta parte del diseño después de haber terminado la aplicación.

En este artículo veremos dos marcos de trabajo diferentes (pero complementarios) que pueden trabajar de forma conjunta o independiente y que le ayudarán a superar la complejidad del acceso a datos persistentes en aplicaciones J2EE, más específicamente:

  • Oracle TopLink, un poderoso marco de trabajo de persistencia objeto-relacional que proporciona un mecanismo producitivo y altamante flexible para acceder a datos relacionales.
  • Spring, un marco de tabajo de aplicaciones J2EE, publicado bajo la Apache Software License. Spring proporciona servicios para todas las capas arquitecturales, pero es particularmente potente en cuanto a la persistencia proporcionando una aproximación consistente para acceder a datos. Como verá, la capa de servicios de persistencia de Spring se acompaña con una implementación del patrón de diseño J2EE Data Access Objects (DAO).

Utilizar juntos TopLink y la capa DAO de Spring puede ofrece una aproximación muy productiva y de alto rendimiento para persistir Plain Old Java Objects (POJOs), que son objetos normalmes Java que no son JavaBeans, ni Beans de entidad ni de sesión, en bases de datos relacionales.

Esta aproximación es una alternativa a la tradicional solución de persistencia de objetos J2EE; los Beans de Entidad de EJB 2.x; que han caído en deshuso por muchas razones, entre las que se incluye un modelo de programación embarullado, una baja productividad de desarrollo, y un mal testeo. Además, el lenguaje de consultas de EJB (EJBQL) en su forma sin adornos (sin extensiones propietarias) está muy limitado. Sin embargo, lo más importante es que los beans de entidad presentan muchas restricciones al diseño OO evitando el uso de herencia real, por lo que no son los más ideales para modelos de persitencia sofisticados. (Por otro lado, los POJOs son especialmente útiles para crear un modelo de objetos para problemas de dominio específicos).

La aproximación a la persistencia presentada en este artículo le permitirá persistir POJOs sin restricciones en el diseño OO, que según nuestro punto de vista es una mejor estrategia que los EJBs.

Aunque nos enfoquemos en este artículo en algunas extensiones de TopLink y Spring, las tecnologías que generalmente representan; mapeo objeto-relacional, implementacion de capas de persistencia como abstracciones DAO, separación de la configuración mediante la Inversión de Control (IoC); ofrecen lecciones de arquitectura para los desarrolladores J2EE. Dicchas tecnologías son capaces de persistir modelos de dominio orientados a objetos que capturan importantes conceptos de negocio. Normalmante se dice que ofrecen persistencia transparente, la habilidad que tiene un producto de mapeo objeto-relacional de manipular directamente datos almacenados en una base de datos relacional (utilizando un lenguaje de programación de objetos).

Veremos algunas de esas capacidades y ofreceremos guías generales, las mejores prácticas y estrategias básicas para persistencia J2EE que usted podrá utilizar sin importar las herramientas específicas o los marcos de trabajo que utilice.

Empecemos con una rápida introducción de algunos de los retos del desarrollo de aplicaciones que abarcan los mundos de Java y de las bases de datos relacionales.

La Necesidad de Automatizar el Acceso a Datos desde Java

El API JDBC define una forma estándar para que el código Java se comunique con bases de datos relacionales, pero es de un nivel tan bajo que su uso no es productivo para los desarrolladores de aplicaciones. Se puede crear código JDBC de forma más productiva y menos propensa a errores utilizando una capa de abtracción sobre JDBC (como los paquetes JDBC de Spring o un buen marco de trabajo JDBC propietario, por ejemplo).

Sin embargo, el desarrollador (usted) aún debe realizar mucho trabajo sucio de bajo nivel. Por ejemplo, sacar los datos de la base de datos requiere seleccionar valores en PreparedStatements de JDBC y extraerlos requiere el uso de ResultSets.

Las herramientas de abstracción (como iBATIS SQL Maps) que funcionan a un nivel un poco más alto que los marcos de trabajo JDBC puede automatizar la mayor parte del mapeo JDBC-a-SQL. Sin embargo, los desarrolladores siguen siendo los responsables de escribir el SQL, detectar cuando los objetos persistidos está "sucios" (no están sincronizados con la base de datos), y escribir el extenso código Java para almacenar objetos.

Algunas veces trabajar a ese nivel tan bajo es apropiado. Algunas aplicaciones no requieren más automátización que la proporcionada por dichas aproximaciones. Pero la mayoría si lo necesitan. Lo que se necesita es el nivel de automatización proporcionado por las sofisticadas herramientas de Mapeo Objeto-Relacional (ORM).

Introducción al Mapeo O-R

Seguro que habrá oido algo sobre el Mapeo Objeto-Relacional (ORM). Quizás lo haya utilizado, si no es así, ciertamente debería considerar su utilización en sus aplicaciones Java o J2EE.

ORM ayuda a reducir la llamada diferencia de impedancia Objeto-Relacional; el abismo entre el modelo orientado a objetos de una aplicación Java bien diseñada (basada en el modelado de cosas y conceptos del mundo real) y el modelo relacional de un esquema de base de datos (basado en aproximaciones matemáticas para almacenar datos). Este abismo es sorprendentemente ancho. Una aproximación ingénua; el simple mapeo de una clase a una tabla; falla en muchos aspectos. Por ejemplo:

  • Las relaciones entre objetos Java se mapean como uniones en la base de datos, y son costosas de seguir a menos que el mapeo esté optimizado.
  • Los objetos normalmente participan en árboles de herencia, un concepto externo al modelo relacional.
  • El modelo relacional estándar no proporciona los tipos extensibles de un lenguaje como Java.
  • Si las relaciones se escriben completamente en SQL, sus relaciones con objetos Java podrían no ser tan claras.

El ORM lo realiza un marco de trabajo de persistencia, que sabe como consultar la base de datos para recuperar objetos Java, y cómo persistir dichos objetos en su representación en las tablas y columnas de la base de datos. Los mapeos se definen en metadatos, típicamente ficheros XML. Algunas herramientas populares proporcionan herramientas gráficas para hacer más sencilla la construcción de mapeos. (TopLink es el líder en esto, con su excelente Mapping Workbench, como puede ver en la Figura 1:


Figura 1: TopLink Mapping Workbench

Con ORM, la automatización se extiende no sólo al mapeo de objetos a filas y columnas de la base de datos, sino también a la deteción de objetos sucios y la escritura en la base de datos con el menor número de actualizaciones SQL; requerimientos que son apropiados para la mayoría de las aplicaciones y se pueden cumplir más fácilmente utilizando marcos de trabajo.

Beneficios Principales de ORM

ORM tiene un larga historia, y no es específico de Java. Sin embargo, se ha vuelto particularmente popular entre los desarrolladores Java. ORM tiene tantos propósitos que juntos pueden añadir una enorme ganancia de productividad. Específicamente:

  • ORM elimina el requerimiento de escribir SQL para cargar y persistir el estado de los objetos. Aunque aún se tiene que escribir consultas, una buena herramienta ORM debería hacerlo más sencillo. Y se verá liberado de la codificación asociada con JDBC.
  • ORM le permite crear un modelo de dominio apropiado sin muchos de los problemas asociados con el modelo relacional. Puede pensar en términos de objetos, en vez de en filas y columnas.
  • ORM puede realizar detección automática de cambios, eliminando una tarea propensa a errores del ciclo de vida de los desarrolladores.
  • ORM puede mejorar la portabilidad entre bases de datos reduciendo la dependencia del SQL específico de la base de datos, que se puede abstraer detrás de la herramienta ORM.

El efecto de ORM sobre el rendimiento de una aplicación dependerá del escenario. Para operaciones de actualización basadas en set, el rendimiento de ORM será menor que el JDBC directo, pero en muchos casos ORM puede mejorar el rendimiento en comparación a la codificación manual de código JDBC, permitiendo el ajuste fino de estrategias como las relaciones que serían difíciles de codifica a mano.

Algunas veces, como hace TopLink, ORM va agarrado de la mano de sofisticados macanismos de caché que pueden mejorar el rendimiento. La mejora que obtendrá del caché dependerá de la naturaleza de su aplicación.

Cuándo y Cómo elegir ORM

ORM tiene su escepticos. Especialmente en el espacio .NET ORM ha sido mirado con sospecha, y recientemente este escepticismo también se ha expresado en voz baja en el mundo Java.

En vez de teorizar, dibujemos nuestra propia experiencia práctica, a lo largo de numerosos proyectos J2EE. Usado adecuadamente, ORM puede reducir el esfuerzo de desarrollo y mejorar el mantenimiento. No es algo inhabitual ver un ahorro del 30 ó 40% en la cantidad de código Java necesario al adoptar una solución ORM, en vez de JDBC. Esto es una gran ganancia, porque todo el esfuerzo ahorrado se puede invertir en implementar características de negocio. Es simplemente irresponsable el ignorar el beneficio potencial disponible a través del uso de ORM en las apliaciones correctas, en el entorno adecuado.

Las experiencias negativas con herramientas ORM suelen ser el resultado de intentar usarlo cuando no es apropiado. ORM produce buenos resultados siempre que no lo fuerce donde no cabe. Aquí tiene algunas guías básicas:

  • Entienda su base de datos objetivo:
    No piense que usar ORM le permite ignorar el SQL y el módelo de búsquedas de su base datos. El mapeo Objeto-Relacional es una herramienta para hacer lo que usted quiera hacer más fácil; no le libera de la necesidad de entender qué es lo que usted quiere hacer. (No apreciar los matices de la base de datos y su SQL probablemente es la principal causa de problemas de resultados con ORM).
  • No tenga miedo de usar SQL si es necesario:
    Funciona bien en muchos escenarios. Un buen producto ORM como TopLink le permitirá lanzar consultas SQL. Pero algunas veces necesitará realizar actualizaciones basadas en set o invocar a prodecimientos almacenados.
  • Haga su investigación antes de comprometerse con un producto de ORM:
    No todos los productos ORM son iguales. Asegurese de evaluar dos o tres alternativas desarrollando un perfil de conceptos que refleje sus necesidades. Este ejercicio le ayudará a asegurar que su utilización de ORM es apropiada en términos de rendimiento. Al igual que en el desarrollo empresarial en general, es vital mitigar cualquier riesgo de rendimiento en los inicios del proyecto. Además, las funciones de mapeo de su herramienta ORM no deberían suponer mucha sobrecarga.
  • Sepa cuándo utilizar ORM:
    ORM funciona particularmente bien para aplicaciones OLTP que actualizan entidades individualmente y realizan operaciones basadas en set de forma poco frecuente, como las aplicaciones que actualizan los registros de clientes y sus pedidos asociados de forma individual.
  • Y, cuando no utilizarlo:
    ORM no es siempre la mejor opción. No es apropiado para:
    • Aplicaciones que realizan frecuentes actualizaciones de numerosos registros.
    • Aplicaciones OLAP, porque normalmente las bases de datos ofrecen mencanismos de programación nativos. (En general, J2EE podría no ser la mejor elección para OLAP).
    • Las bases de datos o entornos operativos repletos de código SQL y llamadas a procedimientos almacenados como único mecanismo para recuperar y actualizar datos. En dichos casos, una aproximación basada en JDBC podría ser la mejor opción; iBATIS SQL Maps también brilla en estos escenarios. (Observe sin embargo, que un buen producto ORM, como TopLink, puede funcionar con la mayoría de los esquemas existentes y con procedimientos almacenados, por eso aún podría considerar la utilización de ORM en dichos escenarios).
    • Aplicaciones que se sirven mejor con aproximaciones directas basadas en SQL, en dichas aplicaciones la lógica de negocio está codificada dentro de la base de datos, o forzadas por restricciones de integridad, y que le dan a los usuarios una "ventana de datos", permitiendo que el usuario los edite. En aplicaciones como éstas, ORM tiene menos que ofrecer porque los objetos en general, tienen menos que ofrecer; más allá de una ilusión de orientación a objetos, se puede ganar muy poco modelando las tablas de la base de datos como objetos de dominio.

Hoy en dia hay varias buenas herramientas ORM a su disposición, incluyendo tanto comerciales (TopLink, el producto ORM para Java más antiguo, y varias implementaciones de JDO) como de código abierto (como Hibernate o implementaciones de JDO). Simplemente elija una de ellas, no es necesario que se enrrolle. (En el pasado, era muy común desarrollar marcos de trabajo ORM personales, pero hoy en día, no tiene sentido: es un enorme gasto cuyos resultados nunca son tan buenos como las soluciones genéricas comerciales o de código abierto). Echemos un vistazo más de cerca a la utilización de TopLink y veamos un ejemplo de utilización de un marco de trabajo ORM, y los beneficios de productividad que proporciona.

Un ejemplo de Trabajo con una Herramienta ORM

TopLink Mapping Workbench le permite definir mapeos persistidos en ficheros XML o en clases Java. (Los ficheros de mapeos se pueden leer y editar). Mapping Workbench lee los metadatos de la base de datos, maneja las relaciones clave externas, ayudando a eliminar los errores de mapeo.

Hay dos aproximaciones principales para realizar consultas en productos ORM; lenguajes de consultas basados en strings (como HQL de Hibernate, o el propio SQL), y lenguajes de expresión basados en API, como el lenguaje de expresiones de TopLink. Aunque los lenguajes de expresión podrían parecer (superficialmente) más verbosos, pueden garantizar una semántica más correcta.

Aquí tiene un ejemplo de una consulta Java basada en el lenguaje de expresión de TopLink:

ExpressionBuilder builder = new ExpressionBuilder();

    Expression exp = builder.get("address").get("country").equal("USA");
    exp = exp.and(builder.get("address").get("pCode").equal("27615"));
    exp = exp.or(builder.get("address").get("country").equal(""));

   session.readAllObjects(Employee.class,exp);
		

Como se puede ver en las Figuras 2 y 3, el TopLink Mapping Workbench también le permite construir consultas utilizando una aproximación visual:


Figura 2: Oracle TopLink Expression Builder


Figura 3: Seleccionar una clave de consulta utilizando el TopLink Expression Builder

Las expresiones de TopLink son muy potentes, y soportan conceptos relacionales avanzados como GROUP BY. Sin embargo, usted siempre puede utilizar SQL con TopLink si necesita 'golpear el metal'.

Como puede ver en esas imágenes, TopLink Mapping Workbench le permite definir consultas basadas en Java mientras mira directamente a su modelo de datos, sin escribir código Java. Las consultas se graban como metadados.

Sin importar la herramienta ORM específica que utilice, debe masterizar el producto, y su base de datos.

El Marco de Trabajo Spring, ORM y la Persistencia

El marco de trabajo Spring es uno de los marcos de trabajo de código abierto lideres en aplicaciones J2EE que proporciona servicios para todas las capas arquitecturales:

Algo más sobre Spring

Spring es un marco de trabajo de aplicaciones multicapa; algo así como un "marco de trabajo de marcos de trabajo de acoplamiento ligero". Entre sus características, se incluyen:

  • Un contenedor de Inversión de Control (IoC) (el paquete Spring Core) que soporta la Inyección de Dependencias, una técnica pionera para configurar aplicaciones basadas en POJO. Spring es el marco de trabajo más popular del espacio IoC.
  • Un marco de trabajo Java AOP (Aspect-Oriented Programming) puro (el paquete Spring AOP) que permite que los puntos de corte transversal se puedan aplicar a POJOs, lo que permite un soporte sofisticado del control de transaciones declarativas en varios entornos.
  • Un marco de trabajo MVC flexible. Spring también se integra con soluciones de la capa Web, como Struts, WebWork, Tapestry, o JSF.
  • Una aproximación común a la persistencia (el paquete Spring DAO).
  • Soporte remoto, trabajando con EJBs, JMS y otras funcionalidades empresariales (el paquete Spring Context).
  • Integración con numerosos productos de terceras partes, incluyendo el programador Quartz y el motor de plantillas Velocity.

El ámbito de Spring va más allá de esta breve lista, aquí tiene algunos recursos donde encontrar información adicional:

Al contrario que los marcos de trabajo de una sóla capa (como Struts), Spring es una aplicación marco de trabajo que facilita una aproximación clara y por capas a la arquitectura de una aplicación. Spring no impone esta arquitectura, pero hace más sencillo seguir las buenas prácticas. La arquitectura típica de una aplicación Spring consta de la capa de presentación, la capa de servicios, el interface DAO y la capa de implementación, y una capa de objetos de dominio persistentes.

En términos de persistencia de objetos, es la capa de interfaces DAO la que dirige el acceso a los datos, implementa las consultas y otras operaciones de persistencia. Echemos un vistazo en profundidad a esa capa, primero en términos genéricos y luego veremos en el código que la capa DAO de Spring se puede utilizar en conjunción con una herramientas ORM (como TopLink).

Beneficios de la Capa de Abstracción DAO

Un interface DAO bien diseñado puede ocultar totalmente la tecnología de persistencia especifica a los objetos de la capa de servicios. Por ejemplo, puede implementar el mismo interface DAO con TopLink o Hibernate, sin impactar en el código llamante.

Esto es bueno, porque reduce la dependencia de una herramienta ORM particular, y proporciona un grado de aprovechamiento futuro. Los conceptos de acceso datos no cambiarán en los próximos años, pero la tecnologías que implementan el DAO si lo harán. Incluso áun más importante, esto significa que usted puede probar los objetos de la capa de servicios sin acceder a una base de datos, simulando DAOs.

Como mecanismo general (junto con las líneas de Eric Evans en la noción de Repositorios (puede encontrar más información en Domain-Driven Design) los interfaces DAO normalmente ofrecen estos tipos de métodos:

  • Buscadores, para recuperar ejemplares de objetos persistentes, estos métodos se implementan utilizando el interface de consultas de la herramienta ORM.
  • Métodos para grabar, para persistir nuevos objetos.
  • Métodos para borrar, para borrar objetos persistidos en la base de datos.
  • Funciones agregadoras, para contar objetos u otras funciones agregadoras. Consultar la base de datos mediante la agregación normalmente es mucho más rápido que interactúar con una gran cantidad de entidades persistentes.

Una Mirada en Profundidad a la Capa DAO de Spring

En una arquitectura Spring típica, los DAOs son objetos del patrón Strategy, que aíslan los objetos de la capa de servicio de la tecnlogía específica para obtener y grabar los objetos persistentes.

Spring soporta varias herramientas ORM y marcos de trabajo de persistenca, incluyendo (aunque no limitado a) TopLink, Hibernate, JDO (Java Data Objects), iBATIS SQL Maps, y Apache OJB (ObjectRelational Bridge).

Spring proporciona una aproximación consistente para trabajar con todas estas herramientas, pero no intenta abstraer complemente la herramienta ORM, porque hacer eso sería contraproductivo. Así, por ejemplo, las implementaciones de interfaces DAO usará el API de consulta nativo de la herramienta ORM: Spring no intenta crear una abstracción de consultas, que sería menos poderoso que los productos líderes en ORM.

Cómo puede influir Spring en cualquier ORM

Para que los interfaces DAO sean independientes de la tecnología de persistencia, necesitamos resolver algunos problemas importantes. Spring proporciona aquí una ayuda interesante, especialmente en las áreas de manejo de excepciones: adquisición y liberación de recursos: y control de transaciones.

El Manejo de Excepciones de Spring

Dos características clave del manejo de excepciones de Spring le permiten permanecer independiente de la tecnología de persistencia. Primero, utiliza un árbol basado en clases de excepciones genéricas de acceso a datos (la Figura 4 muestra las clases más importantes del árbol) que pueden ocultar cualquier mecanismo de excepciones de la ORM. Este árbol de excepciones se puede extender fácilmente. Así, por ejemplo, puede escribir código de una capa de servicio para manejar DataIntegrityViolationException (violación de una restricción de una clave primaria), sin preocuparse de la heramienta de acceso a datos utilizada, que podría ser JDBC, TopLink, JDO, Hibernate u otro marco de trabajo soportado. Este árbol es extensible incluso sin modificar el código de Spring, si desea añadir mapeos para condiciones de error únicas de su base de datos o su herramienta de persistencia.


Figura 4: Diagrama UML del árbol de clases de excepciones de Spring.

Segundo, la aproximación al manejo de excepciones de Spring usa excepciones no chequeadas. La utilización de este tipo de excepciones funciona particularmente bien en conjunción con un árbol de excepciones, porque sólo es necesario capturar una subclase particular que podría ser recuperable. Capturar subclases de excepciones chequeadas es menos útil, porque aún se necesita capturar la clase base. (Observe que JDBC siempre ha sido un API raro, en términos de su utilización de excepciones chequeadas: TopLink y JDO, por ejemplo, usan excepciones no chequeadas. En su versión 3, Hibernate cambiará de excepciones chequeadas a no chequeadas.

Adquisición y Liberación de Recursos

Uno de los mayores retos de trabajar con cualquier tecnología de acceso a datos es que se debe adquirir y liberar correctamente recursos como las conexiones JDBC o las sesiones ORM incluso si ocurren errores.

(Una sesión ORM es una unidad de trabajo transacional manejada por la herramienta ORM. Una sesión contiene un conjunto de objetos asociados con la transación, algunos de los cuales podrían haber sido modificados durante el curso de la transación, y a partir de los cuales la herramienta ORM genera SQL para actualizar la base de datos. Por lo tanto, el control de sesiones es primordial para la integridad de los datos).

Spring resuelve el problema de la adquisición y liberación de recursos utilizando una aproximación de retrollamadas. El marco de trabajo es el responsable de adquirir y liberar los recursos, mientras que el desarrollador de la aplicación immplementa código en un método de retrollamada que realiza la operación de persistencia necesaria con el recurso deseado. Así los desarrolladores de la aplicación se enfocan en las necesidades únicas de su aplicación, en vez de escribir código de fontanero.

Las clases de ayuda que proporcionan esta funcionalidad son plantillas condicionales, y Spring proporciona una aproximación consistente entre muchos APIs, donde cada adquisición y liberación de recurso es un problema, como JDBC, JNDI y JMS.

Control de Transaciones y unión de Threads

La estrategia de adquisición y liberación de recursos de Spring está integrada con su soporte de control de transaciones. Es importante obtener el mismo recurso para cada operación de la misma transación. Mientras JTA y JCA podrían proporcionar soporte de este tipo en un entorno totalmente J2EE (dependiendo de la herramienta de persistencia), Spring proporciona soporte para ello en cualquier entorno, incluyendo entornos J2SE. La configuración que necesita Spring es mucho más simple que la que necesita JCA.

Spring realiza esto uniendo recursos como una conexión JDBC o una sesión de TopLink o de Hibernate al thread actual. Muchos desarrolladores de aplicaciones habrán implementado dicho soporte en sus propias aplicaciones. Sin embargo, la solución de Spring no sólo tiene el mérito de ser mucho más sofisticada que las soluciones caseras (con soporte para suspensión de transaciones y muchos otros valores añadidos complejos de implementar), sino que elimina la necesidad de escribir y mantener dicho código personalizado. De nuevo para los problemas genéricos es mejor una solución genérica.

Clases y Métodos de Conveniencia

Spring proporciona clases de conveniencia para simplificar el trabajo con cada herramienta de persistencia soportada.

Por ejemplo, las clases de soporte para JDBC, TopLink, e Hibernate proporcionan métodos de consulta y grabado que reducen dichas operaciones a una única línea de código, como la siguiente (un consulta Hibernate utilizando la clase de conveniencia HibernateTemplate de Spring):

List customers = hibernateTemplate.find("from Customer c where c.age > ?", age);
		

O está (una consulta TopLink usando la clase de conveniencia TopLinkTemplate de Spring):

List customers = toplinkTemplate.findByNamedQuery(Customer.class,"findAllCustomersOlderThan",args);
		

Dichos métodos de conveniencia puede reducir significativamente la cantidad de código para acceder a datos requerida por una aplicación que utiliza el API nativo de la herramienta de persistencia y trata con la adquisición y liberación de recursos.

Spring y TopLink son una pareja particularmente buena. TopLink es un producto complejo, por eso la arquitectura consistente y la receta de "plantillas" que trae Spring pueden proporcionar a los usuarios unas guías muy útiles.

Un ejemplo de Persistencia en Acción: Un Proyecto de Integración de Spring y TopLink.

Ahora disponible en OTN, la integración Spring/TopLink construida sobre el patrón arquitectural consistente establecido por la integración de Spring con otros marcos de trabajo ORM. El código de integración de Spring-TopLink lo escribió el equipo de Oracle TopLink, y será donado al proyecto Spring. Tanto Oracle como la comunidad Spring planean dar soporte a los usuarios para la integración.

La integración Spring-TopLink le permite disfrutar de un modelo de programación consistente siempre que utilice TopLink dentro o fuera de un servidor de aplicaciones. Esta integración incluye:

  • Clases de conveniencia, como plantillas TopLink, que hacen que muchas de las operaciones de TopLink sean muy sencillas y proporciona un modelo simplificado para implementar operaciones más complejas eliminando la búsqueda de recursos.
  • Utilidades de traducción de excepciones, que pueden traducir excepciones de Toplink al árbol DataAccessException de Spring.
  • Integración con el control de transaciones de Spring. Una aplicación de ejemplo, PetClinic, demuestra la integración y le ayudará a iniciarse con Spring y TopLink. Aunque PetClinic es una aplicación sencilla, ilustra algunas de las mejores prácticas, y puede servir como una plantilla arquitectural para usos más sofisticados de Spring y TopLink.

Por defecto, la aplicación PetClinic se ejecuta con HSQL (HypersonicSQL, un sencilla base de datos, puro Java que es útil para pruebas o para aplicaciones con requerimientos de acceso a datos muy sencillos). Pero con una reconfiguración correcta en la capa de TopLink, puede utilizar Oracle o cualquier otra base de datos (en el paquete de descarga está disponible la reconfiguración para utilizar PetClinic con Oracle).

Cuando utilice Spring con TopLink, debe asegurarse de:

  • Utilizar consultas con nombre. Esta ha sido una buena práctica ampliamente recomendada por los consultores de TopLink.
  • Use la clase TopLinkTemplate para obtener y usar sesiones TopLink, en vez de escribir su propio código para manejar sesiones TopLink. Esto le ahorrará el tiempo y el esfuerzo y asegurará un manejo de errores consistente en su aplicación.
  • Sigua la práctica arquitectural normal de Spring, y oculte el uso de TopLink detrás de los interfaces DAO.

Conclusión

La persistencia es vital para el éxito de los proyectos J2EE. Espero que este artículo le convenza de los valores propuestos por ORM. Si su proyecto se puede beneficar de ORM, entonces su productividad se verá recompensada.

El marco de trabajo Spring proporciona servicios para todas las capas de las aplicaciones Java/J2EE. En este artículo nos hemos enfocado en su aproximación a la persistencia, pero de hecho es sólo un parte todo lo que proporciona Spring. Spring proporciona un estilo de arquitectura consistente para que las aplicaciones J2EE accedan a datos persistentes. Se integra bien con todas las tecnologías de ORM, incluyendo Oracle TopLink. El compromiso de Oracle con la integración Spring-TopLink son buenas noticias para ambas comunidades.

Si usted es un usuario de TopLink, apreciará la simplicación y consistencia que puede traer a su código. Pero no necesita sacrificar ninguna parte del poder de TopLink. Si es un usuario de Spring, habrá obtenido la opción de utilizar TopLink para sus requerimientos de ORM.

Próximos Pasos:

Algo más sobre topLink

TopLink probablemente sea el marco de trabajo ORM más maduro. Primero fue desarrollado en Smalltalk en 1994. Desde 1997, su foco principal ha sido Java. Hoy en día TopLink se puede utilizar tanto fuera como dentro de un servidor de aplicaciones J2EE. Aunque ahora es propiedad y está soportado por Oracle, funciona con cualquiera de las principales bases de datos, no sólo con Oracle. Funciona con todos los servidores de aplicaciones J2EE (o incluso fuera de ellos).

TopLink proporciona muchas funcionalidades ORM. Como todas las buenas herramientas ORM, TopLink le permite persistir POJOs (Plain Java Objects), que tienen un mínima dependencia de los APIs de TopLink. También proporciona varios mapeos avanzados, incluyendo soporte para tipos de árboles y BLOB (con streaming). También proporciona un sofisticado soporte para búsqueda optimista, lo que puede producir grandes beneficios, si se utiliza apropiadamente.

Es importante observar que TopLink no es puramente una herramienta ORM ya que también proporciona una solución de caché integrado (incluyendo coordinación del caché entre clusters), un soporte de consultas ricas, capacidades O-X, varias características de rendimiento (como la "indirección") que optimizan las interacciones con la base de datos, y el control de transaciones.

Con Oracle JDeveloper 10g (10.1.3) developer preview puede obtener un único IDE que le permite definir sus mapeos TopLink, y construir visualmente sus páginas JSF y JSP, además de escribir su código Java. Oracle JDeveloper integra el Mapeador TopLink que ayuda a los desarrolladores a mapear visualmente objetos Java en tablas de la base de datos utilizando una poderosa capa de persistencia TopLink. Los desarrolladores que utilizan TopLink como su arquitectura de persistencia para sus clases Java personalizadas pueden ocultar las características de unión de datos comunes en la capa del modelo ADF para construir interfaces de usuario JSP de forma simplificada, uiXML o aplicaciones Swing.

Con lo años, TopLink ha sido reconocido como un lider en proporcionar servicios de persistencia para sistemas Java. Aquí puede encontrar más recursos sobre Oracle TopLink:

Sobre el Horizonte: ¿Qué hay de EJB 3.0?

La especificación Enterprise JavaBeans (EJB) 3.0, que está siendo desarrollada actualmente bajo el JCP como JSR-220, incluirá una especificación de persistencia POJO que dejará obsoleto el actual modelo de beans de entidad. Esta iniciativa también ha traído alguna incertidumbre al espacio de trabajo del Mapeo Objeto-Relacional.

A pesar de todo, si su aplicación puede beneficiarse de ORM, debería adoptar una herramienta ORM, y disfrutar de sus ganancias en productividad. Si elige un producto líder, como Oracle TopLink, Hibernate, o Kodo JDO, puede estar seguro que el vendedor le proporcionará una estrategia de migración a la persistencia de POJOs de la JSR-220; dentro de dos años podría estar utilizando las mismas herramientas que ahora, pero a través de un API diferente. (La migración del modelo de entidades EJB 2.X al modelo de persistencia de POJO de la JSR-220 será más complicada).

Además, la especificación EJB 3.0 no saldrá a la luz hasta primeros del 2006; mientras tanto, es vital tener una solución de Mapeo Objeto-Ralacional viable y productiva.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.