Encapsulating the business logic with a POJO façade - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 276

This fetch group definition lists the names of the fields that reference related
objects that must be eagerly loaded. In addition to specifying fields of the Pending-
Order class, it specifies the menu items of the pending order's restaurants and the
menuItem of each of the pending order's line items. Detaching a pending order
when this fetch group is active will result in the JDO implementation detaching
those objects as well.
At the time of this writing, however, a JDO implementation that supported this
fetch group definition was not available, and in order to have a working example I
used Kodo JDO' s per-field fetch configuration mechanism, which is used for both
eager loading and detachment. To detach the PendingOrder and its related
objects, we need to add the corresponding fields to the Kodo JDO' s FetchConfig-
uration before calling KodoPersistenceManager.detach() , which is Kodo JDO' s
equivalent to PersistenceManager.detachCopy() .
Because the JDOPlaceOrderFacadeResultFactory calls the Kodo JDO API s, it
must use a Spring JdoTemplate to execute a callback class, which downcasts the
JDO PersistenceManager to KodoPersistenceManager . As a result, the design con-
sists of the classes shown in figure 7.9. JDOPlaceOrderFacadeResultFactory instan-
tiates a KodoJDODetachObjectCallback and executes it using the JdoTemplate .
KodoJDODetachObjectCallback configures the Kodo FetchConfiguration and
calls the KodoPersistenceManager to detach the PendingOrder . Let's take a
detailed look at these classes.

<<interface>>
PlaceOrderFacadeResultFactory

JdoCallback

make(statusCode, pendingOrder)

JDO
PlaceOrderFacade
ResultFactory

KodoJDODetach
ObjectsCallback

Kodo JDO

JdoTemplate

Kodo
Persistence
Manager

Fetch
Configuration

Figure 7.9 The design of the JDOPlaceOrderFacadeResultFactory