| Pattern Name |
Description |
How BC4J Implements It |
| Data Access Object |
Avoids unnecessary marshalling overhead by implementing dependent objects
as lightweight, persistent classes instead of each as an Enterprise Bean.
Isolates persistence details into a single, easy to maintain class. |
BC4J view objects automate the implementation of data access for reading
data using SQL statements. BC4J entity objects automate persistent storage
of lightweight business entities, an EJB 1.1-compliant implementation
of the EJB 2.0 "local entity bean", not yet available in many EJB servers
due to the emerging nature of the EJB 2.0 specification. BC4J view objects
and entity objects cooperate to provide a sophisticated, performant data
access objects layer where any data queried through a view object can
optionally be made fully updatable without writing any "application plumbing"
code.
|
| Model/View/Controller |
Cleanly separates the roles of data and presentation, allowing multiple
types of client displays to work with the same business information. |
The BC4J Application Module Session Bean provides a generic implementation
of an MVC "application object" that simplifies exposing the application
data model for any application or service, and facilitates declaratively
specifying the boundaries of a logical unit of work. Additional UI-centric
frameworks and tag libraries provided help the developer implement the View
and Controller layers. |
| Session Façade |
Avoids inefficient client access of Entity Beans and inadvertent exposure
of sensitive business information by wrapping Entity Beans with a Session
Bean. |
BC4J application modules are designed to implement a coarse-grained "service
façade" architecture in any of their supported deployment modes.
When deployed as EJB Session Beans, they provide an implemention the Session
Façade pattern automatically. |
| Value
Object |
Avoids unnecessary network round-trips by creating one-off "transport"
objects to group a set of related attributes needed by a client program.
|
BC4J provides an implementation of a generic Row object, which is a metadata-driven
container of any number and kind of attributes that need to be accessed
by a client. You can work with the generic Row interface and do late-bound
getAttribute("Price") and setAttribute("Quantity")
calls, or optionally generate early-bound row interfaces like OverdueOrdersRow,
to enable type-safe method calls like getPrice and setQuantity.
The BC4J Row object can be introspected at runtime to describe the number,
names, and types of the attributes in the row, enabling sophisticated, generic
solutions to be implemented. |
| Page-by-Page
Iterator |
Avoids sending unnecessary data to the client by breaking a large collection
into page-sized "chunks" for display. |
BC4J provides an implementation of a generic RowSet interface which manages
result sets produced by executing View Object SQL queries. RowSet allows
the developer to set a desired page-size, for example 10 rows, and page
up and down through the query results in these page-sized chunks. Because
data is retrieved lazily, only data the user actually visits will ever
be retrieved from the database on the backend, and in the client tier
the number of rows in the page can be returned over the network in a single
roundtrip.
|
| Fast Lane
Reader |
Avoids unnecessary overhead for read-only data by accessing JDBC API's
directly. This allows an application to retrieve only the attributes that
need to be displayed, instead of finding all of the attributes by primary
key when only a few attributes are required by the client. Typically, implementations
of this pattern sacrifice data consistency for performance, since queries
performed at the raw JDBC level do not "see" pending changes made to business
information represented by Enterprise Beans. |
BC4J View Objects read data directly from the database for best performance,
however they give developers a choice regarding data consistency. If updateability
and/or consistency with pending changes is desired, the developer need only
associate the View Object with the appropriate Entity Objects whose business
data is being presented. If consistency is not a concern, View Objects can
simply perform the query with no additional overhead. In either case, the
developer never has to write JDBC data access code. They only provide appropriate
SQL statements in XML descriptors. |
| Front Controller |
Centralizes view management (navigation, templating, security, etc.) for
a Web application in a single object that handles incoming client requests.
|
The Oracle UIX web application framework's UIX Controller servlet implements
this design pattern, managing page rendering, event handler, page flow,
etc. |
| Factory Pattern |
Allows runtime instantiation of an appropriate subclass of a given interface
or superclass based on externally-configurable information. |
All BC4J framework component instantiation is effected through factory
classes allowing runtime substitution of specialized components to facilitate
application customization. |
| Entity Façade |
Provides a restricted view of data and behavior of one or more business
entities. |
The BC4J view object can surface any set of attributes and methods from
any combination of one or more underlying entity objects to furnish the
client with a single, logical value object to work with. |
| Value Messenger |
Keeps client value object attributes in synch with the middle-tier business
entity information that they represent in a bidirectional fashion. |
BC4J's value object implementation coordinates with a client-side value
object cache to batch attribute changes to the EJB tier and receive batch
attribute updates which occur as a result of middle-tier business logic.
The BC4J Value Messenger implemenation is designed to not require any kind
of asynchronous messaging to achieve this effect. |
Bookmark
