Core J2EE Patterns
This is a brief summary of the key design patterns and their main purpose or benefit. See Sun's Core J2EE Patterns for the detail.
Data Access Object
- Decouple application code and data access code
Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.
Transfer Object
- Collates all required attributes avoiding multiple remote calls.
Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
Note: Do not use business Transfer Objects in the constructors of entity beans as this tightly couples the application layer with the data source layer. Use another transfer object (which has all the attributes appropriate to creating the enity bean).
Typically all members of the transfer object are public, avoiding the need for get and set methods, but this is a design choice on case-by-case basis.
Transfer Object Assembler
- Builds composite Transfer Objects from different business components.
Use the Transfer Object Assembler when you need to build a data model from a number of different business components.
See also Composite Entity.
Value List Handler
- Provides a list of Transfer Objects
Session Facade
- Acts as the business interface for clients, combining data from multiple business objects. De-couples client from the business object layer. Centralises security and transaction control.
Business Delegate
- De-couples presentation tier components from business services. May provide data caching.
Service Locator
- Hides implementation details of the business service lookup code. Reduces overheads of resource lookup and may cache resources. Protects against container provider specific handle implementation.
Composite Entity
- Manages a set of interrelated persistent objects.
Use Composite Entity to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity beans. A Composite Entity bean represents a graph of objects. E.g. Rather than have an Orders entity bean and an OrderLines entity bean, use the Composite Entity model to implement retrieving both orders and their associated order lines within a single BMP entity bean. I can't imagine how this could be used with CMP entity beans, so I presume it's only relevant to BMPs.
See also Transfer Object Assembler
Resources
-- Frank Dean - 4 Apr 2003
Related Topics: DevelopmentSetup