Transfer Object Assembler

En una aplicación de la plataforma J2EE, los componentes de negocio del lado del servidor se implementan utilizando beans de sesión, beans de entidad, DAOs, etc. Los clientes de la aplicación necesitan acceder a datos que frecuentemente se componen de múltiples objetos.

Problema

Los clientes de aplicaciones normalmente solicitan los datos del modelo o parte del modelo para presentarlos al usuario o para usarlos en un paso de procesamiento intermedio antes de proporcionar algún servicio. El modelo de la aplicación es una abstracción para los datos de negocio y la lógica de negocio implementada en el lado del servidor como componentes de negocio. Un modelo se podría se expresar como una colección de objetos que se han juntado de una manera organizada. En una aplicación J2EE, el modelo es una colección de objetos distribuidos como beans de sesión, beans de entidad, DAOs u otros objetos. Para que un cliente obtenga los datos del modelo, debe acceder individualmente a cada objeto distribuido que define el modelo. Esta aproximación tiene varios inconvenientes:

Como el cliente debe acceder a todos los componentes distribuidos individualmente, hay un acoplamiento fuerte entre el cliente y los componentes de negocio del modelo sobre la red.

El cliente accede a los componentes distribuidos mediante la capa de red, y eso puede provocar una degradación del rendimiento si el modelo es complejo y con numerosos componentes distribuidos. La degradación de la red y del cliente ocurre cuando el modelo de la aplicación implementa varios componentes de negocio distribuidos y el cliente interactúa directamente con esos componentes para obtener los datos del modelo. Todos esos accesos resultan en llamadas a métodos remotos que sobrecargan la red e incrementan las comunicaciones entre el cliente y la capa de negocio.

El cliente debe reconstruir el modelo después de obtener sus partes desde los componentes distribuidos. Por lo tanto, el cliente necesita tener suficiente lógica de negocio para construir el modelo. Si la construcción del modelo es compleja y se ven implicados en su definición numerosos objetos, podría haber una sobrecarga adicional en el rendimiento del cliente debido al proceso de construcción. Además, el cliente debe contener lógica de negocio para manejar las relaciones entre los componentes, lo que resultará en un cliente más complejo y todavía más grande. Cuando el cliente construye el modelo de la aplicación, la construcción sucede en el lado del cliente. La construcción de modelos complejos podría resultar en una sobrecarga importante en el rendimiento del lado del cliente para clientes con recursos limitados.

Como el cliente está fuertemente acoplado con el modelo, los cambios en el modelo requieren cambios en el cliente. Además, si hay diferentes tipos de clientes, es más difícil manejar los cambios entre todos los tipos de cliente. Cuando hay acoplamiento fuerte entre el cliente y la implementación del modelo, lo que ocurre cuando el cliente tiene conocimiento directo del modelo y maneja las relaciones de los componentes de negocio, los cambios en el modelo necesitan cambios en el cliente. Además, hay otro problema de duplicación de código para acceder al modelo, lo que ocurre cuando una aplicación tiene muchos tipos de clientes. Esta duplicación hace que los clientes (su código) sea difícil de manejar cuando el modelo cambia.

Solución

Utilizar un Transfer Object Assembler para construir el modelo o submodelo requerido. El Transfer Object Assembler usa Transfer Objects para recuperar los datos de los distintos objetos de negocio y otros objetos que definen el modelo o una parte del modelo.

El Transfer Object Assembler construye un Transfer Object compuesto que representa los datos de diferentes componentes de negocio. El Transfer Object transporta datos del modelo al cliente en una sola llamada a método. Como los datos del modelo pueden ser complejos, se recomienda que el Transfer Object no sea modificable. Es decir, el cliente obtiene esos Transfer Objects con el único propósito de usarlos para presentaciones y procesamientos de sólo-lectura. Si está permitido que los clientes hagan cambios en los Transfer Objects.

Cuando el cliente necesita los datos del modelo, y si el modelo está representado por un único componente genérico (como un Composite Entity), el proceso de obtención del modelo es muy simple. El cliente simplemente solicita el componente genérico para su Transfer Object compuesto. Sin embargo, la mayoría de las aplicaciones del mundo real tienen un modelo compuesto de una combinación de muchos componentes genéricos y específicos. En este caso, el cliente debe interactuar con numerosos componentes de negocio para obtener todos los datos necesarios para representar el modelo. El inconveniente inmediato de esta aproximación se puede ver en que los clientes se convierte en fuertemente acoplados con la implementación del modelo (elementos del modelo) y que los los clientes tienden a realizar numerosas llamadas a métodos remotos para obtener los datos de cada componente individual.

En algunos casos, un único componente genérico proporciona el modelo o parte del modelo como único objeto Transfer Object (simple o compuesto). Sin embargo, cuando varios componentes representan el modelo, un único Transfer Object (simple o compuesto) podria no representar todo el modelo. Para representar el modelo, es necesario obtener Transfer Objects de varios componentes y ensamblarlos en un Transfer Object Compuesto. El servidor, no el cliente, debería realizar la construcción del modelo "al-vuelo".

Implementación y Participantes

El diagrama de secuencia del patrón es el siguiente

• TransferObjectAssembler: El TransferObjectAssembler es la clase principal de este patrón. Construye un nuevo Transfer Object basado en los requerimientos de la aplicación cuando el cliente solicita un Transfer Object compuesto. Entonces TransferObjectAssembler localiza los ejemplares BusinessObject requeridos para recuperar los datos para construir el Transfer Object compuesto. Los BusinessObjects son objetos de la capa de negocio como beans de entidad o de sesión, DAOs, etc.
• Cliente: Si el TransferObjectAssembler se implementa como un objeto Java normal, el cliente normalmente es un Session Facade que proporciona la capa controladora para la capa de negocio. Si el TransferObjectAssembler se implementa como un bean de sesión, el cliente puede ser un Session Facade o un Business Delegate.
• BusinessObject: BusinessObject participa en la construcción del nuevo Transfer Object proporcionando los datos requeridos por el TransferObjectAssembler. Por lo tanto, el BusinessObject es un rol que cumple un bean de sesión, un bean de entidad, un DAO, o un objeto normal de Java.
• DataAccessObject: Es un rol que pueden cumplir un bean de sesión, un bean de entidad, o un DAO. Cuando el ensamblador necesita obtener los datos directamente desde el almacenamiento persistente, para construir el Transfer Object, puede utilizar un DAO.