| Pattern Name |
Description |
How ADF Implements It |
| 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 ADF Application Module provides
a generic implementation of a Model/View/Controller "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. Addtional UI-centric frameworks and tag libraries provided in JDeveloper
10g help the developer implement the View and Controller layers.
|
| Interface / Implementation Separation |
Cleanly separates the API or Interface for components
from their implementation class.
|
ADF Business
Components enforce a logical separation of client-tier accessible functionality
(via interfaces) and their business tier implementation (described further in
this
whitepaper). JDeveloper handles the creation of custom interfaces and
client proxy classes automatically.
|
| Service
Locator |
Abstracts the technical details of
locating a service so the client and use it more easily.
|
ADF application modules are looked up using a simple
configuration object which hides the low-level details of finding the service
instance behind the scenes. For web applications, it also hides the
implementation of the application module pool usage, a lightweight pool of
service components that improves application scalability.
|
| Inversion
of Control |
A containing component
orchestrates the lifecycle of the components it contains, invoking specific
methods that the developer can overrides at the appropriate times so the
developer can focus more on what the code should do instead when it should get
executed.
|
ADF framework components contain a
number of easy-to-override methods that the framework invokes as needed during
the course of application processing. The whitepaper
Most
Commonly Used Methods in ADF Business Components has a section that
covers the most commonly written and overridden methods on each ADF business
component base class.
|
| Dependency
Injection |
Simplifies application code, and
increases configuration flexibility by deferring component configuration and
assembly to the container.
|
The ADF framework
configures all its components from externalized XML metadata definition files.
The framework automatically injects dependent objects like view object
instances into your application module service component and entity objects
into your view rows at runtime, implementing lazy loading. It supports runtime
factory substitution of components by any customized subclass of that component
to simplify on-site application customization scenarios. Much of the ADF
framework functionality is implemented via dynamic injection of validator and
listener subscriptions that coordinate the framework interactions depending on
what declarative features have been configured for each component in their XML
metadata.
|
| Active
Record |
Avoids the complexity of "anything
to anything" object/relational mapping, by providing an object that wraps a row
in a database table or view, encapsulates the database access, and adds domain
logic on that data.
|
ADF entity objects handle the
database mapping functionality you use most frequently, including inheritance,
association, and composition support, without having to think about
object/relational mapping. They also provide a place to encapsulate both
declarative business rules and one-off programmatic business domain
logic.
|
| Data
Access Objects |
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.
|
ADF view objects automate the implementation of data access for
reading data using SQL statements. ADF 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. ADF 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.
|
| Session
Facade |
Avoids inefficient client access
of Entity Beans and inadvertent exposure of sensitive business information by
wrapping Entity Beans with a Session Bean.
|
ADF
application modules are designed to implement a coarse-grained "service facade"
architecture in any of their supported deployment modes. When deployed as EJB
Session Beans, they provide an implemention the Session Facade 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.
|
ADF
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. The developer 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(). Smarter than just a simple "bag
'o attributes" the ADF 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.
|
ADF 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. Since 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.
|
ADF 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 his/hew 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 ADF supports using Apache Struts as your front-controller
servlet.
|
| (Bean) Factory |
Allows runtime instantiation and configuration of an appropriate
subclass of a given interface or superclass based on externally-configurable
information.
|
All ADF framework component
instantiation is done based on XML configuration metadata through factory
classes allowing runtime substitution of specialized components to facilitate
application customization.
|
| Entity Facade |
Provides a restricted view of data and behavior of one or more
business entities.
|
The ADF 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.
|
ADF'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 ADF Value Messenger
implemenation is designed to not require any kind of asynchronous messaging to
achieve this effect.
|
| Continuations |
Gives the developer the simplicity and productivity of a stateful programming model with the scalability of a stateless web
solution.
|
ADF's application module pooling and state management functionality combine to deliver this developer value-add. This avoids dedicating appliation server tier resources to individual
users, but supports a "stateless with user affinity" optimization that you can tune.
|
Bookmark
