Fig18.Data Access Object
class diagram
Participants and Responsibilities
The following sequence diagram shows clearly the interaction
between the various participants in this pattern.
The Business Object represents the data client. It is the object
that requires access to the data source to obtain and store data. A Business
Object may be implemented as a session bean, entity bean, or some other Java
object, in addition to a servlet or helper bean that accesses the data
source.
The Data Access Object is the primary object of this pattern. The
Data Access Object abstracts the underlying data access implementation for the
Business Object to enable transparent access to the data source. The Business
Object also delegates data load and store operations to the Data Access
Object.
Data Source represents a data source implementation. A
data source could be a database such as an RDBMS, OODBMS, XML repository, and
so forth.
Transfer Object represents a Transfer Object used as a
data carrier. The Data Access Object may use a Transfer Object to return data
to the client. The Data Access Object may also receive the data from the client
in a Transfer Object to update the data in the data source.
3.3.1.3. Session Facade
We use a session bean as a facade to encapsulate the complexity
of interactions between the business objects participating in a workflow. The
Session Facade manages the business objects, and provides a uniform
coarse-grained service access layer to clients.
The Session Facade abstracts the underlying business object
interactions and provides a service layer that exposes only the required
interfaces. Thus, it hides from the client's view the complex interactions
between the participants. It manages the interactions between the business data
and business service objects that participate in the workflow, and it
encapsulates the business logic associated with the requirements. Thus, the
session bean (representing the Session Facade) manages the relationships
between business objects. The session bean also manages the life cycle of these
participants by creating, locating (looking up), modifying, and deleting them
as required by the workflow.
Use Cases and Session Facades
So, how can we identify the Session Facades through studying use
cases? Mapping every use case to a Session Facade will result in too many
Session Facades. This defeats the intention of having fewer coarse-grained
session beans. Instead, as we derive the Session Facades during our modeling,
it is essential to consolidate them into fewer numbers of session beans based
on some logical partitioning.
For example, for our application, we grouped the interactions
related to managing some units into a single facade. The use cases Create,
Change Information, View information, and so on all deal with the
coarse-grained entity object Account. Creating a session bean facade for each
use case is not recommended. Thus, the functions required to support these
related use cases could be grouped into a single Session Facade called
Management Session Facade.
Structure: Figure 19 shows the class diagram
representing the Session Facade pattern.
| 
