Java Reference
In-Depth Information
real application would get pendingOrderId from the HttpServletRequest and
pass it to the business tier rather than calling the JDO API s directly.
The main benefit of JDO datastore identity is that you do not have to add a pri-
mary key field to a class. This simplifies the domain model and enables you to per-
sist classes that don't have a primary key field. It works well when the application
never needs to access an object's persistent identity.
Datastore identity makes it difficult for the application to access and manipulate
an object's persistent identity. The first problem is that the application must call
JDOHelper.getObjectId(object) to get the object identifier, which clutters the
code with calls to JDO . This makes the presentation tier more complicated because
it would have to call this method to get the identity of a detached object instead of
simply asking the object. It also breaks encapsulation because the presentation tier
needs to know that the business tier uses JDO . You could avoid this problem by hav-
ing the business tier call getObjectId() and return a DTO containing the object
and its ID to the presentation tier, but that requires extra DTO classes.
Another problem with datastore identity is that the JDO object ID string is too
long to be embedded within a web page. The ID string is usually the fully qualified
class name concatenated with the primary key. If the application embedded these
values in URL s, the result would be ugly, hard-to-read URL s.
The third problem with datastore identity is that the persistent identity is dif-
ferent than the database primary key, which makes it very difficult to write JDO
and JDBC/ i BATIS code that works together. In order to convert between a primary
key and a datastore identity, you would have to write code that relied on the ven-
dor-specific format of the JDO object ID string.
Using datastore identity is certainly worthwhile because you don't have to add
an ID field to your domain objects. However, because of its drawbacks you should
only use it for objects whose persistent identity is never accessed by the applica-
tion. Examples of classes in the Food to Go domain model that can use datastore
identity are PendingOrderLineItem , MenuItem , and TimeRange because their
primary keys are never used. For other classes you should use application identity
and add primary key fields.
Adding primary key fields is only one of the changes you must make to your
domain model. You might also need to make some changes when persisting class
hierarchies.
5.1.2
Persisting interfaces
Persisting a class hierarchy is generally straightforward because JDO supports each
of the mapping schemes described in chapter 4. A class can be mapped to its
 
 
Search WWH ::




Custom Search