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.
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.
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.
No hay comentarios:
Publicar un comentario