Directriz: Identificación de beans de identidad
Esta directriz trata la forma en que identificar y modelar beans de entidad que se necesitan para una aplicación J2EE.
Relaciones
Elementos relacionados
Descripción principal

Introducción

Esta directriz se centra en identificar los beans de entidad. En la sección Directriz: beans de entidad se proporciona ayuda adicional sobre beans de entidad. En la sección Directriz: Enterprise JavaBeans (EJB) se proporciona ayuda adicional sobre EJB.

Identificación de beans de entidad

A menudo las clases de entidad (consulte la sección Producto de trabajo: clases de análisis) son buenas candidatas como beans de entidad, puesto que los beans de entidad se utilizan para los datos persistentes. Los beans de entidad corresponden a entidades empresariales con un estado persistente. Proporcionan servicios que implementan lógica específica de la entidad empresarial. Otra característica de los beans de entidad es que pueden proporcionar sus servicios a muchos clientes a la vez. El contenedor EJB maneja la coordinación con estos clientes y con sus transacciones.

Los beans de entidad se utilizan para proporcionar persistencia, pero también pueden encapsular lógica empresarial. En general, un bean de entidad sólo debería contener lógica empresarial relacionada con el bean de entidad y todos los objetos de datos dependientes. En general, se debería quitar la lógica de bean entre entidades y colocarla en beans de sesión para minimizar el acoplamiento entre los beans de entidad.

Modelado de beans de entidad

Consulte la sección Directriz: identificación de Enterprise JavaBeans (EJB) para obtener más información.

Granularidad

La granularidad hace referencia al tamaño de los datos que un EJB de entidad representa. La granularidad apropiada puede depender de la versión de la especificación EJB que se esté utilizando.

Con anterioridad a EJB 2.0, se recomendaba que los EJB de entidad siempre tuviesen una granularidad grande; típicamente representando grandes grupos de datos agrupados de varias tablas de bases de datos. Esto se debe a que cada entidad EJB da lugar a sobrecargas; en particular sobrecargas relacionas por el tratar con elementos remotos. Por ejemplo, los artículos de una línea de detalle en una factura o las celdas en una hoja de cálculo tienen una granularidad demasiado fina y no se debería acceder a los mismos con frecuencia por la red. En contraste, agrupaciones lógicas de las entradas de una factura, o un subconjunto de celdas en una hoja de cálculo se pueden modelar como una entidad EJB si se requiere lógica empresarial para los datos.

Esto ha cambiado de alguna manera con EJB 2.0: la introducción de interfaces locales reduce parte de estas sobrecargas y permite modelar objetos con una granularidad más fina como EJB. En la sección Concepto: visión general de Java 2 Platform Enterprise Edition (J2EE) se describen las interfaces locales y remotas. Un interfaz local no tiene la sobrecarga asociada con una interfaz remota, permitiendo que beans fuertemente acoplados interactúen más eficientemente. Las interfaces locales son particularmente útiles para entidades con una granularidad fina que se utilizan para formar una entidad mayor, siendo la entidad mayor responsable de la creación y destrucción de las partes. Los clientes utilizan la interfaz remota de la entidad mayor, que a su vez, utiliza las interfaces locales para interactuar con sus partes.

De cualquier manera, si un bean de entidad tiene una relación de composición con otra clase, se puede elegir modelar esta otra clase como una clase Java normal en lugar de un bean de entidad. Si se está utilizando la persistencia gestionada por contenedor, se hace referencia a esta clase Java como una "clase de valor dependiente". Las clases de valor dependiente son más sencillas y se desarrollan y prueban con más rapidez que los beans de entidad, y son una buena opción, suponiendo que la clase compuesta no requiera características de bean de entidad. Algunas de las limitaciones de las clases de valor dependiente son:

  • No pueden contener referencias de bean de entidad.
  • Son "get" y "set" por valor, lo que tiene algún coste de rendimiento, pero que habilita el acceso desde interfaces remotas.

Encapsulación

Hay que considerar el agrupar un conjunto de beans de entidad relacionados en una fachada de bean de sesión para proporcionar una interfaz lógica para la manipulación de entidades empresariales que corresponden a los EJB de entidad. Consulte la sección Directriz: identificación de beans de sesión para obtener más información.

Una aproximación similar se da con un bean de entidad para que encapsule un conjunto de otros, generalmente dependientes, beans de entidad locales. Los clientes remotos acceden a todos los datos a través del bean de entidad "principal". En Core J2EE Patterns - Composite Entity Pattern ([ALU01]) se discute esta alternativa; sin embargo, se recomienda una fachada de bean de sesión como un método más fácil para gestionar las relaciones de beans de entidad.