COMPOSITE ENTITY

Permite implementar objetos de negocio persistentes que estén compuestos por diferentes objetos relacionados. 

Ésta patrón es implementado indirectamente por Hibernate, siendo totalmente transparente. Mediante la definición del Mapping de Hibernate, se realiza la composición de la entidad, permitiéndose cierta flexibilidad en cómo realizar dicha composición.

Los objetos del negocio tienen relaciones entre sí que son necesarias para representar correctamente el modelo del dominio. Cuando se accede a objetos remotos se podría generar una sobrecarga de red al transmitir todos los objetos relacionados que pueden ser necesarios para el cliente.

En las aplicaciones  empresariales, los objetos Composite Entity no deberían  ser expuestos directamente al cliente. Para esto se  puede usar un Session Façade. Para hacer transferencia de datos se usa el patrón Transfer Object.

Solución

Utilizar Composite Entity para modelar, representar y manejar un conjunto de objetos 
persistentes relacionados en vez de representarlos como beans de entidad específicos individuales. Un bean Composite Entity representa un grupo de objetos.

Para entender esta solución, primero definamos que significan los objetos persistentes y discutiremos sus relaciones.

Un objeto persistente es un objeto que se almacena en algún tipo de almacenamiento. Normalmente múltiples clientes comparten los objetos persistentes. Los objetos persistentes se pueden clasificar en dos tipos: objetos genéricos y objetos dependientes.

Un objeto genérico es autosuficiente. Tiene su propio ciclo de vida y maneja sus relaciones con otros objetos. Todo objeto genérico podría referenciar o contener uno o más objetos. El objeto genérico normalmente maneja el ciclo devida de estos objetos. De ahí, que esos objetos sean conocidos como objetos dependientes. Un objeto dependiente puede ser un simple objeto auto-contenido o podría a su vez contener otros objetos dependientes.

El ciclo de vida de un objeto dependiente está fuertemente acoplado al ciclo de vida del objeto genérico. Un cliente sólo podría acceder al objeto dependiente através del objeto genérico. Es decir, los objetos dependientes no se exponen directamente a los clientes porque su objeto padre (genérico) los maneja. Los objetos dependientes no pueden existir por sí mismos. En su lugar, siempre necesitan tener su objeto genérico (o padre) para justificar su existencia.

 Estructura

El diagrama de secuencia de la siguiente imagen muestra las interacciones para este patrón:

Participantes y Responsabilidades

CompositeEntity: CompositeEntity es un bean de entidad genérico. Podría ser un objeto genérico, o podría contener una referencia a un objeto genérico.

Coarse-Grained Object: Un objeto genérico es un objeto que tiene su propio ciclo de vida y que maneja sus propias relaciones con otros objetos.

DependentObject1, DependentObject2, y DependentObject3: Un objeto dependiente es un objeto que depende de un objeto genérico el cual gobierna el ciclo de vida del objeto dependiente. Un objeto dependiente puede contener otros objetos dependientes; así podría existir un árbol de objetos dentro del Composite Entity.

Estrategias: Esta sección explica las diferentes estrategias para implementar el patrón Composite Entity. Las estrategias consideran posibles alternativas y opciones para objetos persistentes (genéricos y dependientes), y la utilización deTransfer Objects.