Probablemente la Capa de Persistencia sea después de la Capa de Presentación uno de las elecciones más esenciales para que en un proyecto podamos centrarnos en el negocio y no dediquemos más tiempo del necesario en temas técnicos.
Es habitual, en esta Capa más que ninguna: “Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.” y que el patrón de diseño se haya convertido en un auténtico antipatrón (un patrón de diseño que invariablemente conduce a una mala solución para un problema), en este caso al antipatrón
(Goldern Hammer/Martillo de Oro para los que no practiquéis los juegos mentales :D)
Pero no divaguemos más, que el tema de los antipatrones da para muchooooos posts 😉
En este post quería comentar que en la Capa de Persistencia no siempre la opción adecuada es Hibernate, o JPA+Hibernate ahora. Por ejemplo en muchas organizaciones (públicas incluso) el departamento de Arquitectura y Metodología tiene prohibido el uso de estos motores por los problemas y complejidades adicionales que ocasionan (por ejemplo en el rendimiento de la base de datos,…).
En estos casos (como ya he dicho en otros posts) la opción obvia es IBatis (MyBatis ahora)…
Pero en ocasiones incluso IBatis (me resisto al nombre MyBatis…qué representa el My en un producto de este tipo…se personaliza para mi? :)) puede no encajar, sobre todo por la necesidad de mapear clases a tablas en XML, aunque herramientas como Abator son capaces de generar a partir de las tablas los mapeos.
En estos casos quedaría la opción obvia de usar JDBC directamente, la de usar el soporte de Spring para JDBC: Spring JDBC (he de reconocerlo Spring es mi Golden Hammer y le encuentro aplicación en cualquier sitio :)) o la de usar otro framework/producto aún más sencillo que IBatis.
Hasta el momento (y salvo alguna excepción que también la hay) en estos casos siempre he optado por Spring JDBC sobre todo por la extensibilidad, aunque he de decir que Spring JDBC es uno de los módulos de Spring más complejos de usar (y más para lo que ofrecen).
En la actualidad existen algunos frameworks muy interesantes para aquellas ocasiones en las que ni JPA, ni IBatis ni Spring JDBC sean lo que necesitemos.
Regularmente me paseo por 
en la sección de Persistencia para ver qué novedades hay: http://java-source.net/open-source/persistence, pero si me lo permitís os voy a hacer mi personal elección:
(a última hora había incluido 
pero finalmente lo he sacado de la lista y no porque esté en Google Code ni porque esté hecho por un español, sólo lo he hecho porque no soporta las principales bases de datos: Oracle, DB2, SQL Server)
Cada uno tiene sus virtudes e inconvenientes.
Sobre 
:
– Sencillo. Siena no tiene dependencias, ocupa 25Kb y el API está diseñada para ser lo más sencilla posible.
– Intrusivo. Los objetos persistentes extienden de la clase Model(el código depende de Siena). Tampoco es que esto sea un gran problema, no acabamos haciéndolo igual nosotros y además alguien ha cambiado alguna vez de motor de persistencia en un proyecto en marcha. Tiene una forma de trabajar con clases que no heredan de Model
– Similitud con JPA
– Soporte SimpleDB de Amazon, Google App Engine,
– Limitado. El API se ha diseñado para que todas las consultas puedan ser ejecutadas usando sólo un índice. Todas las consultas se realizan sólo sobre una tabla, no se pueden hacer subconsultas ni JOINs y no se puede utilizar OR en una cláusula WHERE. De este modo se consigue que todas las consultas puedan ser realizadas utilizando sólo un índice y así sean lo más rápidas posible. Esta estrategia es la que viene siendo utilizada por las aplicaciones que necesitan ser altamente escalables. Las bases de datos «en la nube» Big Table de Google, SimpleDB de Amazon, utilizan esta aproximación.
– Extensible. La implementación actual utiliza JDBC. La funcionalidad principal de Siena se basa en interfaces que pueden ser implementadas utilizando otros mecanismos de persistencia.
– Ejemplo de uso sencillo:
o Clase Employee
o siena.properties:
o haciendo queries:
– Trabajando con relaciones:
o Clase Pet:
o Clase Person:
En el caso de 
:
– Adaptable: Se puede trabajar con POJOs mapeados a tablas (al estilo Siena o JPA) o con POJOs no mapeados (al estilo Spring JDBC)
– Sencillo:
o Si trabajamos con una clase mapeada a tabla se usaría:
o Si trabajamos con POJOs no mapeados:
– Poca documentación y actividad: el proyecto surge en 2008 y aunque sigue activo su actividad es muy baja.
De 
– Uso:
– Mapeo en package.sequalite:
– Documentación?
– Características avanzadas:
o Soporte paginación
o Lazy loading
o Save y Delete en Cascada
– Herramienta para generación de POJOS a partir de tablas
– Abandonado?
Que con cuál me quedo?
SeQuaLite tiene algunas características que no tienen ni Siena ni Persist pero pierde en el resto, sólo lo usaría como base para evolucionarlo.
Siena, teniendo en cuenta cómo funciona la pregunta lógica es porqué no usar JPA…quizás porque soporta Google App Engine, o porque es extensible o por el lenguaje de consultas, o porque no requiere dependencias ni configuración, ni cacheos,…
Persist si eres capaz de lidiar con la falta de documentación (sólo hay un Getting Started) es una opción muy atractiva, un sustituto completo al complejo Spring JDBC y puede que más 🙂
Un poco de Java 
Deja un comentario