Hace un par de semanas hemos liberado nuestro primer proyecto bajo licencia de código abierto: Gorm4Ebean.
Se trata de una librería, muy sencilla, que permite utilizar el API EBean ORM de forma muy similar al API de Grails: GORM.
Personalmente, tengo la mala costumbre de desarrollar muchas (demasiadas) herramientas. Soy de los que se pasan mas tiempo afilando el hacha que cortando, pero es así, que le vamos a hacer. Me parece horrible retorcer una aplicación para encajarla con determinados componentes cuando se puede desarrollar una capa intermedia que abstraiga de toda la fontanería... debe ser deformación de cuando estuve con el Framework PA. Aunque ahora, "lo que mas se lleva" son los DSLs. Tenemos DSL para cualquier cosa: configuración del componente A, scripting, persistencia, configuración del componente B (otro DSL distinto del de A, porque como el dominio es distinto, pues lenguaje distinto...), etc. Algunos son interpretados, otros compilados. La verdad, demasiados... aunque con Groovy se hacen como churros.
Ahora con la crisis, cada vez estamos mas concienciados con el reciclaje y la productividad y zurcir los calcetines y hacer sopa con el cocido de ayer y todas estas cosas....y me he dado cuenta de la pila de herramientas y utilidades que hemos desarrollado durante años y nunca han visto la luz. La mayoría estaban demasiado acopladas a los proyectos (o directamente eran basura), pero otras no...otras se podían haber publicado o reciclado.
Pensándolo detenidamente, nuestro negocio no pasa por comercializar este tipo de herramientas (para el que tenga interés en saber a que nos dedicamos de verdad, nuestra web es www.nortia-in.es ) y la alternativa a publicarlas es dejarlas cogiendo polvo en un cajón.
En el caso de la librería Gorm4Ebean (que lleva un DSL incluido, faltaría mas) la verdad que fue una cosa fortuita: Aplicación Swing con Griffon ... Nos rompemos los cuernos para conseguir sacar GORM de Grails y utilizarlo en un entorno Swing, solamente para darnos cuenta de que la gestión de sesiones de Hibernate no es compatible (o mejor dicho, "duramente compatible") con el modelo de hilos de Swing.
Así que, buscando por internet (bendito StackOverflow) nos topamos con la librería eBean, que es una especie de Hibernate pero "sessionless". La verdad que no es muy conocida. Los proyectos conocidos que la usan son: Play! (un framework web que no conozco muy bien), el famosisimo juego indie Minecraft y ...luego ya debemos de ser nosotros los siguientes.
Pero bueno, funciona bastante bien! El problema es que con GORM tenemos una arquitectura basada en Domain Objects: ya sabes, con la lógica de negocio y los datos todos juntos y revueltos, métodos save(), list(), delete(), etc., nada anemico...
En cambio, eBean a priori parece que encaja mejor en una arquitectura de capas tradicional: VOs anémicos, capa de negocio, capa de DAOs, etc.
Entonces ¿que hacemos? ¿Tiramos todo y rehacemos la aplicación con la arquitectura de capas? ¿O hacemos algo con eBean para que encaje con todo el código que ya teníamos hecho?
Obviamente, hemos elegido la segunda opción y de ahí sale la librería gorm4ebean.
