RIAlity soporta Lazy Loading

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 :).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *