J2EE Design Pattern : Business Tier Patterns : Composite Entity Design Pattern
|Composite Entity Design Pattern?|
Composite Entity represents a best practice for designing coarse-grained entity beans by grouping parent-dependent objects into a single entity bean.
Deciding whether to use remote or local entity beans. Remote entity beans are associated with network overhead and can degrade the performance of the application when not used appropriately. Local entity beans were introduced in the EJB 2.0 specification and might not be available in older versions. Some containers optimize the inter-entity bean, however such optimization is vendor-specific and not standard.
You want to use entity beans to implement your conceptual domain model.
Use a Composite Entity to implement persistent Business Objects using local entity beans and POJOs. Composite Entity aggregates a set of related Business Objects into coarse-grained entity bean implementations.
Participants and Collaborations
CompositeEntity is the coarse-grained entity bean that contains dependent objects.
DependentBO, DependentEntityBO, and DependentPOJOBO
A dependent object depends on the parent object that manages its lifecycle. A dependent object can contain other dependent objects; thus there might be a tree of objects within the Composite Entity. You can implement dependent objects as local entity beans (e.g. DependentEntity1 and DependentEntity2) or POJOs (e.g. DependentPOJO).
DataStore represents the persistent store to which the business data gets persisted.
EJBContainer invokes the load and store operations. The EJB Specification contains detailed object interaction diagrams, which can help you understand how the EJB container interacts with entity beans to load, store, activate, and passivate.
- Composite Entity Remote Facade Strategy
- Composite Entity BMP Strategies (includingLazy Load, Store Optimization(Dirty Maker) strategies)