domingo, 7 de julio de 2013

PATRÓN TRANSFER OBJECT

CONTEXTO
Las aplicaciones cliente necesitan intercambiar datos con Beans Enterprise.

PROBLEMA
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 transaccionales, 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.

CAUSAS

  • Todos los accesos a un bean enterprise se realizan mediante interfaces remotos. 
  • Normalmente, las aplicaciones tienen transacciones de lectura con mayor frecuencia que las de actualización. 
  • El cliente normalmente solicita valores que son algo más que un atributo o que son dependientes del objeto de un bean enterprise. 
  • El número de llamadas que un cliente hace al bean enterprise impactan en el rendimiento de la red. 


SOLUCIÓN
Utilizar un Transfer Object para encapsular los datos de negocio. Se utiliza una única llamada a un método para envíar 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.

ESTRUCTURA
La siguiente figura muestra el diagrama de clases que representa el patrón Transfer Object en su forma más simple:



Como se ve en este diagrama de clases, el Transfer Object lo construye bajo pedido el bean enterprise y lo devuelve al cliente remoto. Sin embargo, el patrón Transfer Object puede adoptar varias estrategias, dependiendo de los requerimientos.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura contiene el diagrama de secuencia que muestra las interacciones del patrón Transfer Object:

 
Client- Representa al cliente del bean enterprise. El cliente puede ser una aplicación final de usuario, como es el caso de una aplicación que ha sido diseñada para acceder directamente a beans enterprise. El cliente puede utilizar Business Delegate u otro BusinessObject diferente.

BusinessObject- Representa un rol en este patrón que puede cumplir un bean de sesión, un bean de entidad, o un Data Access Object (DAO). BusinessObject es el responsable de crear el Transfer Object y devolverlo al cliente bajo pedido. El BusinessObject también podría recibir datos desde el cliente en la forma de un Transfer Object y utilizar esos datos para realizar una actualización.

TransferObject- TransferObject es un objeto Java serializable referenciado como un Transfer Object. Una clase Transfer Object podría proporcionar un constructor que acepte todos los atributos requeridos para crear el Transfer Object.

CONSECUENCIAS

  • Simplifica el Bean de Entidad y el Interface Remoto 
  • Transfiere Más Datos en Menos Llamadas Remotas 
  • Reduce el Tráfico de Red 
  • Reduce la Duplicación de Código
  • Podría Introducir Transfer Objects Obsoletos 
  • Podría Incrementar la Complejidad Debido a la Sincronización y el Control de Versión 
  • Accesos y Transacciones Concurrentes 


No hay comentarios:

Publicar un comentario