Java Reference
In-Depth Information
System.out.println("\nA yacht is deleted");
aTestClient.delete();
aTestClient.display(SIZE - 1);
System.out.println("Test Completed");
}
}
There are many JDO vendors on the market. The JDO implementation used in the example is the
OpenFusion JDO from Prism Technologies, but I am not endorsing any specific vendor. Choose the
vendor based on your specific requirements. For simplicity, the initialization of the
PersistenceManagerFactory
instance part uses the vendor-specific APIs included in the package:
com.prism.j2ee.connector.jdbc.ManagedConnectFactoryImpl
. This is the only place that
uses a JDO vendor-specific API; everything else uses the standard JDO APIs, with the vendor-specific
implementation behind the scenes. If you use another JDO implementation, you can simply modify that
portion of the code. If your application has access to a JNDI service, you can get a
PersistentManagerFactory
instance via JNDI lookup. Then you do not need to modify code at all
when you switch to another vendor's JDO implementation.
The test client program first instantiates four
Yacht
objects and persists their state into a persistent
store. The persisted objects are then retrieved one by one, and their states are displayed on the
standard output screen. The program then changes the second yacht's name from "Liberty" to
"New_Name." You see the change when the program redisplays the persisted objects' states on the
screen. Finally, the test program deletes the second
Yacht
object from the persistent store. When the
display is refreshed, the second
Yacht
object is gone.
The business logic in the above example is very simple. In the real life, the business rules and logic are
much more complicated and complex domain objects must be handled. You will learn the support of
complex domain objects in the
next section
.
Support for the Complex Domain Object Model
As a Java developer, you must be familiar with object-oriented design and programming. In almost all
enterprise applications, the domain object models are fairly complex, with all kinds of relationships
between classes: association, aggregation, composition, inheritances, and so on. The most notable
relationships are extension or inheritance. These allow the abstraction of common attributes and
behaviors of a set of classes into a base class. All the subclasses inherit the fields and methods from
the super class.
If the objects are to be persisted, however, there is a gap between such an object model and the
relationship model used by relationship databases. Typically, object-to-relationship mapping (O/R
mapping) must be made, and developers must deal with low-level constructs of the database model,
such as rows and columns, and constantly translate them back and forth. In the previous chapters of
this topic, you have learned all the tricks using JDBC APIs to couple your Java objects with underlying
database tables. It is not only tedious, but the code is not 100-percent portable due to the variant of
SQL flavors different databases use.
Container-managed entity EJBs partially solve this problem by postponing the O/R mapping to the
deployment phase. Since you do not need to write any data-store access code, the CMP entity beans
are decoupled from specific database type or even the specific database schema. As
write once, deploy
everywhere
components, they are portable and reusable. However, when you deploy them to a specific
database, you still have to know the relational data model in order to map the persistent fields to the
corresponding table columns and to specify the relational fields in the deployment descriptor.
Moreover, the current CMP entity-bean specification does not support inheritance, one of the most
important features of object-oriented design. This makes it impossible to build a complex domain object
