Transfer Object

Es uno de los patrones más utilizado. Se utiliza para la comunicación, transporte e intercambios de datos negocio especialmente útil en aplicaciones distribuidas.

Se implementa con un objeto que extiende la interfaz Serializable. Es una representación estado/valor de un objeto y se utiliza para encapsular datos de negocio. Se trata de un JavaBeans, con los atributos propios del objeto de dominio con carácter privado, y métodos get y set para acceder y modificar sus valores.

Existen varios enfoques de este patrón. Cuando el Transfer Object modela una tabla relacional y los atributos de la clase son los campos de la tabla, se está utilizando un Domain Value Object. Si se encapsulan atributos de varias tablas, creando una clase que combine sólo los atributos requeridos, se está utilizando un Custom Value Object.

Este patrón, en el contexto JDBC, nos permite representar un conjunto de atributos procedentes de uno o varios objetos de dominio; en el contexto EJB representa eficiencia. Sin embargo, hay que tener cuidado en el diseño porque hay casos en el que puede contener información obsoleta.

Las aplicaciones de la plataforma J2EE implementan componentes de negocio del lado del servidor como beans de sesión y de entidad. Algunos métodos expuestos por los componentes de negocio devuelven datos al cliente. Algunas veces, el cliente invoca a los métodos get de un objeto de negocio varias veces para obtener todos los valores de los atributos.

Los beans de sesión representan los servicios de negocio y no se comparten entre usuarios. Un bean de sesión proporciona métodos de servicios genéricos cuando se implementan para el patrón Session Facade.

Por otro lado, los beans de entidad, son objetos transacionales, multiusuario que representan datos persistentes. Un bean de entidad expone los valores de los atributos proporcionando un método accesor (también referidos como métodos get) por cada atributo que desea exponer.

Toda llamada a método hecha al objeto de servicio de negocio, ya sea a un bean de entidad o a un bean de sesión, potencialmente es una llamada remota. Así, en una aplicación de JavaBeans Enterprise (EJB) dichas llamadas remotas usan la capa de red sin importar la proximidad del cliente al bean, creando una sobrecarga en la red. Las llamadas a métodos de beans enterprise podría penetrar las capas de red incluso si tanto el cliente como el contenedor EJB que mantiene el bean de entidad se están ejecutando en la misma JVM (Máquina Virtual Java), el mismo Sistema Operativo o máquina física. Algunos vendedores podrían implementar mecanismos para reducir esta sobrecarga utilizando una aproximación de acceso más directa pasando por encima de la red.

Según se incrementa la utilización de estos métodos remotos, el rendimiento de la aplicación se puede degradar significativametne. Por lo tanto, utilizar varias llamadas a métodos get que devuelven simples valores de atributos es ineficiente para obtener valores de datos desde un bean enterprise.

Todos los accesos a un bean enterprise se realizan mediante interfaces remotas. Cada llamada a un bean enterprise potencialmente es una llamada a un método remoto con sobrecarga de red.

Normalmente, las aplicaciones tienen transacciones de lectura con mayor frecuencia que las de actualización. El cliente solicita los datos desde la capa de negocio para su presentación, y otros tipos de procesamientos de sólo-lectura. El cliente actualiza los datos de la capa de negocio con mucha menos frecuencia con la que los lee.

El cliente normalmente solicita valores que son algo más que un atributo o que son dependientes del objeto de un bean enterprise. Así, el cliente podría invocar varias llamadas remotas para obtener los datos necesarios.

El número de llamadas que un cliente hace al bean enterprise impactan en el rendimiento de la red.

Al utilizar un Transfer Object que encapsula los datos de negocio, se utiliza una única llamada a un método para enviar y recuperar el Transfer Object. Cuando el cliente solicita los datos de negocio al bean enterprise, éste puede construir el Transfer Object, rellenarlo con sus valores de atributos y pasarlo por valor al cliente.

Los clientes normalmente solicitan más de un valor a un bean enterprise. Para reducir el número de llamadas remotas y evitar la sobrecarga asociada, es mejor el Transfer Objects para transportar los datos desde el bean enteprise al cliente.

Cuando un bean enterprise utiliza un Transfer Object, el cliente hace una sola llamada a un método remoto del bean enterprise para solicitar el Transfer Object en vez de numerosas llamadas remotas para obtener valores de atributos individuales. Entonces el bean enterprise construye un nuevo ejemplar Transfer Object, copia dentro los valores del objeto y lo devuelve al cliente. El cliente recibe el Transfer Object y puede entonces invocar los métodos accesores (o get) del Transfer Object para obtener los valores de atributos individuales del objeto Transfer Object. O, la implementación del Transfer Object podría hacer que todos los atributos fueran públicos. Como el Transfer Object se pasa por valor al cliente, todas las llamadas al ejemplar Transfer Object son llamadas locales en vez de invocaciones de métodos remotos.

·         Estructura (diagrama de clases)

·         Diagrama de secuencia