Java Reference
In-Depth Information
There may be slight variances in the XML MetaData file depending on the JDO implementation you use.
Basically, you specify the inheritance using the
persistence-capable-superclass
attribute within
the
class
tag. The JDO implementation handles all the persistence details for you transparently. It may
even create the database schema, with referential integrity enforced to implement the inheritance
relationship.
The client program accesses the JDO persistent class instances in the same way as it accesses any
Java class instance. As an example, your client code may have the following code snippet:
… …
PersistenceManager pm = pmf.getPersistenceManager();
Employee emp = (Employee) pm.getObjectById(empId);
emp.computeBiweeklyPay();
… …
When the client calls
getObjectById
method, the JDO implementation automatically instantiates an
instance of the correct class, either
ParttimeEmployee
or
FulltimeEmployee
. When the instance's
computeBiweeklyPay
method is called, the correct version is invoked. The polymorphism of the
object-oriented paradigm makes the client-code simple and elegant. You cannot achieve such a level of
simplicity and elegance by using any other data-persistence mechanisms.
In addition to inheritance, your classes can have any type of object relationships such as aggregation
and composition, association, utilization, and so on. All you need to do is specify these relationships in
the XML MetaData file and feed the file to the JDO enhancer.
After leaning the nuts and bolts of JDO, you must be eager to learn how to develop applications using
JDO. This is discussed in the
next section
.
JDO Application Development Process
When designing a JDO-aware application, developers do not have to worry about the database type
and database schema; but there are some best practices you probably want to follow. You should divide
the Java classes into two categories: the
persistent classes
and
business classes
. The persistent
classes are those that contain the data managed in the database, and the business classes are those
that contain the business logic and query the persisted data. In the example code shown in
Listing 23-1
and
Listing 23-2
, the class
Yacht
is persistent, and the class
TestClient
is business.
The persistent classes are very simple Java classes with data members, basic accessor methods, and
(if necessary) some data-manipulation methods. There is no restriction from the JDO specification that
you cannot put the business logic into these persistent classes. As a matter of fact, putting some
business logic into these classes is a more object-oriented approach. However, since the persistent
classes have to be further processed by the JDO implementation, as you will see later, it is
recommended as a best practice to separate business logic from date persistence. The separation
makes the data-persistent class more like simple JavaBean classes and can be generated automatically
by many integrated development environments (IDEs) such as Together Control Center, Forte for Java,
Visual Age, and so on.
The business classes contain all the business logic. They access the persisted data through the
instances of persistent classes. Since JDO provides transparent persistence, there are no database
calls (no SQL) in the business class code. You do not need to make these business classes persistent
capable, which reduces the runtime overhead of the JDO implementation and hence improves the
performance of the application.
The data represented by persistent objects are ultimately stored in the underlying database, and
therefore the objects must be mapped to database entities. This mapping is done by the JDO enhancer
based on the information provided in the XML MetaData file. In many cases, the JDO enhancer also
creates a database schema to support the persistence.
