sábado, 6 de julio de 2013

Entidad compuesta (COMPOSITE ENTITY)



Contexto
Los beans de entidad no pretenden representar todos los objetos persistentes en el modelo de objetos. Los beans de entidad son más adecuados para los objetos de negocio persistentes de coarse-grained.

Problema

En la plataforma Java 2, la aplicación Enterprise Edition (J2EE), los clientes - tales como aplicaciones, JavaServer Pages (JSP) páginas, Servlets, JavaBeans componentes - beans de entidad de acceso vía sus interfaces remotos. Por lo tanto, cada invocación de cliente potencialmente rutas a través de los talones de la red y esqueletos, incluso si el cliente y el bean enterprise están en la misma JVM, sistema operativo, o de la máquina. Cuando los beans de entidad son objetos específicos, los clientes tienden a invocar los métodos más individuales de beans de entidad, lo que sobrecarga de red alta.
Los beans de entidad representan objetos de negocio persistentes distribuidos. Ya sea en desarrollo o la migración de una aplicación para la plataforma J2EE, granularidad objeto es muy importante al momento de decidir lo que debe implementar como un bean de entidad. Los beans de entidad deben representar los objetos de negocio de grano grueso, como los que proporcionan un comportamiento complejo más allá de simplemente obtener y establecer los valores de campo. Estos objetos genéricos suelen tener objetos dependientes. Un objeto dependiente es un objeto que no tiene dominio verdadero significado cuando no se asocia con su matriz de coarse-grained.
Un problema recurrente es la aplicación directa del modelo de objetos a un modelo de Enterprise JavaBeans (EJB) (específicamente beans de entidad). Esto crea una relación entre los objetos bean de entidad sin consideración de los objetos de grano grueso frente de grano fino (o dependiente). La determinación de qué hacer con grano grueso en comparación con grano fino suele ser difícil y se puede hacer mejor a través de las relaciones de modelado en los modelos de Lenguaje Unificado de Modelado (UML).
Hay un número de áreas afectadas por la entidad enfoque de diseño de fine-grained entity:
  • Relaciones Entidad - Directamente cartografía un modelo de objetos a un modelo EJB no tiene en cuenta el impacto de las relaciones entre los objetos. Las relaciones entre los objetos se transforman directamente en las relaciones entre las entidades de frijol. Como resultado, un bean de entidad puede contener o sostener una referencia remota a otro bean de entidad. Sin embargo, el mantenimiento de referencias remotas a objetos distribuidos implica diferentes técnicas y semánticas que mantiene las referencias a objetos locales. Además de aumentar la complejidad del código, se reduce la flexibilidad, ya que el bean de entidad debe cambiar si se produce algún cambio en sus relaciones.
Además, no hay ninguna garantía en cuanto a la validez de las referencias de beans de entidad a otros beans de entidad en el tiempo. Dichas referencias se establecen dinámicamente usando el objeto home de la entidad y la clave principal para esa instancia bean de entidad. Esto implica una sobrecarga de alto mantenimiento de validez verificación de referencias de cada uno de dichos referencia de entidad-bean-de-entidad-bean.
·         Manejabilidad - Implementar objetos de grano fino como entidad frijoles resulta en un gran número de beans de entidad en el sistema. Un bean de entidad se define utilizando varias clases. Para cada componente bean de entidad, el desarrollador debe proporcionar clases para la interfaz de inicio, la interfaz remota, la implementación del bean, y la clave principal.
Además, el recipiente puede generar clases para apoyar la implementación del bean entidad. Cuando se crea el bean, estas clases se realizan como objetos reales en el recipiente. En resumen, el contenedor crea una serie de objetos para apoyar a cada instancia del bean entidad. Un gran número de beans de entidad como resultado más clases y el código para mantener el equipo de desarrollo. También da lugar a un gran número de objetos en el recipiente. Esto puede afectar negativamente al rendimiento de la aplicación.
·         Rendimiento de la red - beans de entidad potencialmente tienen más relaciones de frijol entre las entidades. Los beans de entidad son objetos distribuidos. Cuando un bean de entidad invoca un método en otro bean de entidad, la llamada es potencialmente tratado como una llamada remota por el contenedor, incluso si ambos son beans de entidad en el mismo contenedor o JVM. Si el número de relaciones entidad-bean-de-entidad-frijol aumenta, esto disminuye la escalabilidad del sistema debido a la sobrecarga de la red pesada.

·         Base de datos de dependencia de esquemas - Cuando los beans de entidad son de grano fino, cada instancia del bean de entidad generalmente representa una única fila de una base de datos. Esto no es una aplicación adecuada del diseño bean de entidad, desde beans de entidad son más adecuados para los componentes de grano grueso. De grano fino implementación del bean entidad normalmente es una representación directa del esquema de base de datos subyacente en el diseño bean de entidad. Cuando los clientes utilizan estos beans de entidad de grano fino, que son esencialmente operan en el nivel de fila en la base de datos, ya que cada bean de entidad es en realidad una sola fila. Debido a que el bean de entidad modela directamente una sola fila de base de datos, los clientes se vuelven dependientes del esquema de base de datos. Cuando los cambios de esquema, las definiciones de beans de entidad deben cambiar también. Además, dado que los clientes están operando a la misma granularidad, deben observar y reaccionar a este cambio. Esta dependencia de esquema provoca una pérdida de flexibilidad y aumenta la sobrecarga de mantenimiento siempre que se requieran cambios de esquema.

·          Granularidad de objetos (de grano grueso en comparación con grano fino) - Objeto granularidad impactos transferencia de datos entre el bean enterprise y el cliente. En la mayoría de las aplicaciones, los clientes suelen necesitar un pedazo más grande de los datos de una o dos filas de una tabla. En tal caso, la aplicación de cada uno de estos objetos de grano fino como un bean de entidad significa que el cliente tendría que administrar las relaciones entre todos estos objetos de grano fino. Dependiendo de los requisitos de datos, el cliente podría tener que realizar muchas búsquedas de un número de beans de entidad para obtener la información requerida.
 
Fortalezas:
·  Los beans de entidad son mejor implementados como objetos genéricos, debido a los altos costos asociados a cada bean de entidad. Cada bean de entidad se implementa utilizando varios objetos, como EJB objeto de origen, objeto remoto, la aplicación de frijol, y la clave primaria, y cada uno es dirigido por los servicios de contenedores.
 
·  Las aplicaciones que se asignan directamente esquema de base de datos relacionales para beans de entidad (donde cada fila de una tabla se representa mediante una instancia del bean entidad) tienden a tener un gran número de beans de entidad. Es deseable mantener los beans de entidad de grano grueso y reducir el número de beans de entidad en la aplicación.
 
·  Asignación directa de modelo de objetos de modelo EJB proporciona beans de entidad. Beans de entidad, por lo general se asignan a el esquema de base de datos. Este mapeo fila entidad a la base de datos hace que los problemas relacionados con el rendimiento, manejabilidad, seguridad y gestión de transacciones. Las relaciones entre las tablas se implementan como las relaciones entre beans de entidad, lo que significa que los beans de entidad contienen referencias a otros beans de entidad para poner en práctica las relaciones de grano fino. Es muy caro para gestionar las relaciones entre las entidades de frijol, debido a que estas relaciones se deben establecer de forma dinámica, utilizando los objetos de origen de entidad y las claves principales de los beans enterprise.
 
· Chattiness adicional puede ser observada entre el cliente y los beans de entidad ya que el cliente puede tener que comunicarse con muchos granos de entidad específicos para cumplir con un requisito. Es deseable reducir la comunicación entre dos o más beans de entidad y para reducir el chattiness entre el cliente y la capa bean de entidad.

Solución

Utilice Entidad Compuesta para modelar, representar y gestionar un conjunto de objetos persistentes relacionados entre sí en lugar de presentarlos como beans de entidad de fine-grained entity beans. Un bean Composite Entity representa un gráfico de objetos.
 
Estructura
Si bien hay muchas estrategias en la aplicación del patrón Composite Entity, el primero que se discute es representado por el diagrama de clases en la Figura 8.17. Aquí el Composite Entity contiene el objeto genérico y el objeto genérico contiene los objetos dependientes.






Figura 8.17 Diagrama de clase Composite Entity

El diagrama de secuencia en la Figura 8.18 muestra las interacciones de este patrón. 

 



Figura 8.18 Diagrama de secuencia Composite Entity


 
(Contact Us © 2001-2002 Sun Microsystems)
 

No hay comentarios:

Publicar un comentario