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

7.5.2 Implementing a JDO result factory

Now that you have seen the Hibernate implementation of the PlaceOrderResult-
Factory , let's look at the JDO implementation. The JDOPlaceOrderFacadeResult-
Factory must call the JDO detached object API s to detach the PendingOrder and its
related objects. To do this, it must configure the JDO fetch groups to describe the
graph of objects to detach. One option is to add the reference and collection
fields to each class's default fetch group, as shown in table 7.1

Table 7.1 Configuring the default fetch groups to load the required objects

Fields to add to the
default fetch group

Class

PendingOrder lineItems

restaurant coupon

PendingOrderLineItem menuItem

Restaurant menuItems

This is certainly the easiest approach, but because default fetch groups also affect
object loading, it will cause the complete graph of object to be loaded each time a
PendingOrder is loaded. This is usually not desirable because loading objects
unnecessarily can impact performance. A better approach is to use either custom
fetch groups or a vendor-specific mechanism such as Kodo JDO' s per-field fetch
configuration mechanism (described in chapter 5). This approach will not affect
object loading elsewhere in the application because only the detachment code
activates the custom fetch groups or uses the vendor-specific mechanism.
According to the JDO 2.0 specification, adding the following fetch group to the
currently active fetch groups will detach the PendingOrder and its related objects:

<class name="PendingOrder">

<fetch-group name="PendingOrder.placeOrderFacade">
<field name="restaurant"/>
<field name="lineItems"/>
<field name="coupon"/>
<field name="restaurant.menuItems"/>
<field name="lineItems#element.menuItem"/>
</fetch-group>

</class>