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