Diario de Programación

Llevo casi toda la semana entretenido, cambiando un poco los módulos ya hechos de una aplicación de escritorio para poder instanciarlos usando Springframework e instanciándolos con Springframework.

El primer módulo lo abordé con la ilusión de probar algo nuevo. Sin embargo, a la hora de escribir el fichero xml de configuración de Springframework empecé a intuir que ese fichero puede ser un verdadero infierno. Tenía abiertos dos editores, en uno la clase java principal del módulo/bean y en el otro el fichero XML. Iba mirando el nombre exacto de los métodos set() para poner el property con el mismo nombre en el fichero XML. Me reordaba a los viejos tiempos en que programaba en C++ con el vi, sin ningún tipo de IDE. Tenías que ir abriendo los ficheros .h para ver cómo se llamaba exáctamente el método y su parámetros para poder hacer la llamada en tu fichero .cpp

Indagando por google, descubrí que efectivamente, ese es uno de las pequeñas pegas de Springframework: XML grandes y pesados de construir.

Pero me dije, como todo está inventado, seguro que hay un plugin de eclipse para Springframework. Efectivamente, en Springide tienen un estupendo plugin de Springframework para eclipse. Se puede instalar desde eclipse, con "help" -> "software updates" -> "find and install" y poniendo la dirección http://springide.org/updatesite_dev/

La instalación me dio un pequeño problema. No se deja instalar completo, posiblemente porque la versión de eclipse que tengo es la más última y el plugin debe andar un poco por detrás. No obstante, la parte básica del plugin sí se instaló.

Una vez instalado Springide, la construcción del fichero XML es muy agradable. Eclipse ya ofrece ayuda contextual para los ficheros XML, de forma que en cualquier sitio del fichero, pulsando Ctrl-espacio, podemos ver los posibles tags o atributos XML que se pueden añadir siguiendo el DTD que se indique en la cabecera. Con Springide, la ayuda contextual incluye además las clases accesibles para el proyecto o las referencias a los beans ya declarados en el fichero XML.

Me explico, si empezamos a escribir

<bean id="nombre" class="MiC

y justo depués de la C de MiC pulsamos Ctrl-espacio, aparecerá el típico menú con todas las clases accesibles que empiecen por MiC. Seleccionamos una en el menú y se añade automáticamente, incluyendo el paquete.

De la misma forma, si escribimos

<property name="

y pulsamos Ctrl-espacio, aparece un menú con todos las propiedades de la clase en la que estemos poniendo este tag property. Elegimos una y seguimos escribiendo

<property name="propiedadElegida" ref="

y ahora, pulsando Ctrl-espacio sale un menú con todos los beans que ya tenemos declarados, para elegir uno.

Me queda comprobar si se pone en rojo si escribimos una clase, propiedad o bean que no exista.

Sigo con mis pruebas de herramientas/librería de persistencia en base de datos.

Con Hibernate conseguí que funcionara. El ejemplo tonto con una única tabla funcionó casi a la primera. Las HibernateTools - Middlegen para sacar los .xml y los .java a partir de la base de datos me dieron más problemas, pero también funcionaron.

Luego hice pruebas con iBatis. La filosofía de trabajo es distinta, pero el plugin de eclipse me funcionó bien e iBatis genera código hasta un nivel más alto, genera una interface de DAO y una implementación iBatis.

Investigando, descubro que hay una especificación de Java, llamada JPA -Java Persistent API, parte V del tutorial de JEE-, que pretende indicar cómo trabajar con objetos java persistentes -que se guardan más o menos solos en base de datos, sin que el programador tenga que preocuparse de los SQL-.

También descubro que la gente de Apache ha hecho otra especificación similar, JDO, para lo mismo, pero que pretende ser más completa que JPA.

También descubro JPOX, una implementación que cubre las dos especificaciones anteriores: JPA y JDO. Sin embargo, no he conseguido que me funcione. Desde eclipse con el plugin correspondiente me falla al crear las tablas en base de datos y de momento me ha dado pereza crearlas a mano. En cuanto a maven, tienen una mezcolanza rara. Parece que se han quedado en maven 1 según la documentación, pero si te lo bajas con maven 2 está disponible, aunque no encuentro documentación para configurarlo.

Y descubro también que eclipse dali viene con una perpectiva y un "wizard" de proyecto para trabajar con objetos persistentes JPA. Por supuesto, tampoco me ha funcionado.

Y para marear más la perdiz, y todavía sin probar, Glassfish de java lleva una implementación de JPA, hay también otra implemantación de Apache OpenJPA,

En fin, todo un mundo y un abanico de posibilidades. Para probarlas todas no basta con que se paren dos meses la producción, harán falta varios años . De cualquier forma, Hibernate es uno de los que menos problemas me ha dado -descontando los de MiddleGen- y yo creo que sin duda es el más conocido. Aunque la filosofía de trabajo es distinta, iBatis también es conocido y da la impresión de que tienes más control sobre lo que estás haciendo. Ambos están "soportados" por SpringFramework -ver capítulo 12- que sí pienso empezar a usar, así que creo que me centraré un poco más en Hibernate e iBatis.

Hace tiempo que oi hablar de SpringFramework, pero siempre he oido hablar de él asociado a J2EE. Como lo mio son aplicaciones de escritorio y de J2EE no tengo ni idea, nunca he hecho caso de SpringFramework, al igual que no lo he hecho de Structs.

Sin embargo, en algún sitio leí que SpringFramework es un framework en capas, que puedes utilizar más o menos independientemente y algunas de ellas son útiles para cualquier tipo de aplicación, incluidas las de escritorio. Así que me puse a investigar y luego a jugar.

Efectivamente, entre las capas de SpringFramework, hay algunas claramente de J2EE y aplicaciones web -las de nombre JEE y Web-, pero hay otras que no lo son. En concreto, DAO y ORM sirven para acceso a base de datos, AOP para programación orientada a aspectos y Core es un "contenedor" de beans -y no precisamente EJBs-.

En principio me han llamado la atención DAO y ORM, ya que el acceso a base de datos lo uso mucho y cualquier cosa que te ayude es buena. Me hice mi primer ejemplo tonto con DAO y me ha parecido bien. Es sencillo y quita bastante trabajo repetitivo de JDBC -hacer bucles con los ResultSet, componer complejas sentencias SQL, etc-.

Lo de AOP -Programación orientada a aspectos- sé de qué va y no suelo usarlo, así que esa capa en principio me interesa menos y no he probado nada con ella.

En cuanto a Core, el "contenedor de beans", lo he mirado porque ando dándole vueltas a algo parecido y veo la posibilidad de que ya esté implementado algo similar a lo que ando dando vueltas. Mi intención es hacer un ejecutable que lea en un fichero de configuración qué módulos debe instanciar y que estos módulos, sean en principio independientes y sea el main el que "trasiega" datos de uno a otro. El contenedor de beans Core "suena" a algo parecido. De momento, ya me he hecho un ejemplo tonto con Core.

El uso de Core, básicamente consiste en hacer clases bean con métodos set() y get(). Luego, en un fichero XML, dices qué clases bean deben instanciarse, cómo deben inicializarse sus atributos y qué instancias de beans ven a qué otras instancias de beans. Luego, en tu "main", instancias uno de los BeanFactory, como la clase XmlBeanFactory de SpringFramework y listo, se instancian e inicializan automáticamente todos los beans.

Fuera de la web de SpringFramwork, hay una ampliación para clientes "ricos", es decir, para clientes con SWING. Esta ampliación en principio me resulta interesante, pero veo que anda en la versión 0.2.1 y la documentación escasa, por lo que no sé si está todavía bastante "evolucionada".

Seguiré investigando todo esto.