Este sábado estuvimos dándonos un garbeo por Expocómic. Debo decir que siempre he sido un gran lector de cómics de toda la vida, aunque los últimos años tengo algo abandonada esta afición. Lo pasamos realmente bien investigando por toda una exposición abarrotada de entusiastas.

Lee el resto de la entrada »

CICE ha publicado, en su newsletter de Noviembre, una entrevista donde tuve la oportunidad de responder a diversas preguntas sobre la actualidad informática que vivimos. Gracias especiales a CICE por contar conmigo en esta ocasión .

Es remarcable el mimo y el cuidado extremo del que hace gala Adobe en todo lo que hace. Para muestra un botón.

Hace unos pocos días recibí un paquete con una camiseta. La camiseta es un detalle a todos aquellos que estamos poniendo nuestro granito de arena ayudando en la mejora de Flex en todo el mundo. Como se puede ver en las fotos, los chicos de Adobe se han molestado en personlizar el Fx del logo de Flex con los nombres de todos los implicados. Con detalles como este (y otros muchos) no es de extrañar que Adobe goze de tan buena prensa en el mundo. Gracias Adobe!

Esta semana hemos implementado una solución para solventar un problema muy típico al trabajar con productos como BlazeDS/LCDS. Se trata del problema que se origina cuando intentamos recoger un subconjunto de datos de una base de datos y terminamos trayendo por el cable más información de la que esperábamos debido a las relaciones internas en el modelo de datos.

Históricamente, este problema se ha resuelto con una técnica denominada Lazy Loading, de forma que nosotros podemos definir para nuestras entidades que propiedades deben de ser “Lazy” y no deben de ser iniciadas al ejecutar una query. Es decir, se trata de reducir el conjunto de datos que viajaran por la red, accediendo solo a lo necesario.

El problema con BlazeDS y LCDS es la forma de serializar la información para enviar los DTOs hacia el cliente que se lleva a cabo inicializando TODAS las propiedades del objeto, lo que obliga en caso de relaciones complejas a que se empiece a tirar del hilo y terminemos trayendo más datos de los requeridos.

En el caso de GraniteDS, existe una solución basada en externalizers, pero esta es torna demasiado compleja y tediosa de implementar ya que obliga al desarrollador a escribir un par de métodos por entidad definiendo la forma de serializar-deserializar los objetos que viajarán por el cable y especificando que propiedades se añadirán o no. En BlazeDS/LCDS, no existe por el momento una solución oficial para solventar este problema, y en principio no tiene porque haberla ya que esto no es del dominio de este software.

RIAlity, por el contrario, si es una arquitectura que debe solventar este tipo de problemas. Por eso hemos buscado una solución elgante, flexible y transparente al usuario. Esta basada en un Interceptor que se aplica a nivel de DAO. Básicamente lo que se hace es aplicar un aspecto (AOP) a todos los DAOs de forma que se intercepte la llamada a la recogida de resultados. En ese momento se aplica la funcionalidad que elimina el proxy que genera Hibernate de forma que tratemos con las entidades originales y evitemos la lógica interna del proxy que provoca que traigamos esos datos de forma innoportuna.

Esta solución permite que el usuario no se preocupe de las interioridades y decida como quiere tratar con sus entidades. Solo tenemos que indicar en las propiedades habituales si queremos un comportamiento EAGER o LAZY .

Continuando con la serie de videos, vamos a ver una demo de como generar un proyecto de modulo para RIAlity. Este proyecto ya estará configurado para usar las librerias de RIAlity, compilar en la carpeta de despliegue de la aplicación web, compilar usando los reportes del login y el shell para reducir los tamaños del modulo y otras muchas cosas.

De nuevo con unos pocos clicks de raton y en pocos segundos nos ahorraremos la tediosa configuración de todos estos parametros y estaremos listos para desarrollar la funcionalidad que queramos.

En el siguiente video, mostraremos como generar el código de una entidad sobre los próyectos generados en los pasos anteriores.