Guidelines: Identifying Entity Beans
Topics
Introduction
This guideline focuses on identifying Entity Beans. Additional guidance on Entity Beans is provided in Guidelines: Entity Beans. General guidance on EJBs is provided by Guidelines: Enterprise JavaBeans (EJBs).
Identifying Entity Beans
Entity analysis classes (see Artifact: Analysis Class) are often good candidates for entity beans, as entity beans are geared to persistent data. Entity beans correspond to business entities that contain persistent state. They provide services that implement business entity-specific logic. Another characteristic of entity beans is that they can provide their services to many simultaneous clients. The EJB container handles the coordination of these clients and their transactions.
Entity beans are used to provide persistency, but can also encapsulate business logic. Generally, an entity bean should only contain business logic related to the data persisted by the entity bean and any dependent data objects. Generally inter-entity bean logic should be pulled out into session beans to minimize coupling between entity beans.
Modeling Entity Beans
See Guidelines: Identifying Enterprise JavaBeans (EJBs).
Granularity
Granularity refers to the size of the data represented by the entity EJB. The appropriate granularity may depend on the version of the EJB specification being used.
Prior to EJB 2.0, entity EJBs were recommended to always have a large granularity - typically representing large groupings of data grouped from multiple database tables. This is because each entity EJB carried significant overheads - in particular overheads related to being remoteable. For example, line items in an invoice or cells in a spreadsheet are too fine-grained and shouldn't be accessed frequently over a network. In contrast, logical groupings of an invoice's entries, or a subset of cells in a spreadsheet could be modeled as an entity EJB if additional business logic is required for the data.
This changes somewhat in EJB 2.0-the introduction of local interfaces reduces some of these overheads and allows finer-grained objects to be modeled as EJBs. Local and remote interfaces are described in Concepts: J2EE Overview: Enterprise JavaBeans. A local interface doesn't have the overhead associated with a remote interface, allowing tightly coupled beans to interact more efficiently. Local interfaces are particularly useful for fine-grained entities that are used to compose a larger entity, the larger entity being responsible for the creation and destruction of the parts. Clients use the remote interface of the larger entity, which, in turn, uses the local interfaces to interact with its parts.
Nevertheless, if an entity bean has a composition relationship to another class, then you may choose to model that other class as an ordinary Java class rather than an entity bean. If using container-managed persistence, then such a Java class is referred to as a "dependent value class". Dependent value classes are simpler and quicker to develop and test than entity beans, and are a good option, assuming the composed class doesn't require entity bean features. Some limitations of dependent value classes are:
- they cannot contain entity bean references
- are "get" and "set" by value, which has some performance cost, but enables access from the remote interface
Encapsulation
Consider wrapping a set of related entity beans with a session bean fa?ade to provide a logical interface for the manipulation of the business entities that correspond to the entity EJBs. See Guidelines: Identifying Session Beans.
A similar approach is for one entity bean to encapsulate a set of other, generally dependent, local entity beans. Remote clients access all data through the "main" entity bean. Core J2EE Patterns - Composite Entity Pattern ([ALU01] discusses this alternative - however, it recommends the session bean facade as an easier method for managing entity bean relationships.
