Java Reference
In-Depth Information
Persisting Multiple Objects
Our example in Chapter 1 was as simple a persistence scenario as you can imagine. In the next
few sections of this chapter, we will look at a slightly more complicated scenario.
Our example application will provide the persistence technology for an online billboard
application, as shown in Figure 3-1.
Figure 3-1. The online billboard classes
This is a gross simplification of the sort of classes that would be required in a production
application. For example, we make no distinction between the roles of users of the application,
but it should suffice to show some of the simpler relationships between classes.
Particularly interesting is the many-to-many relationship between categories and adver-
tisements. We would like to be able to have multiple categories and adverts, and place any
given advert in more than one category. For example, an electric piano should be listed in the
“Instruments” category as well as the “Electronics” category.
Creating Persistence Classes
We will begin by creating the POJOs for the application. This is not strictly necessary in a new
application, as they can be generated directly from the mapping files, but since this will be
familiar territory, it should help to provide some context for our subsequent creation of the
mapping files.
From the class diagram, we know that three classes will be persisted into the database
(see Listings 3-8, 3-9, and 3-10). Each class that will be persisted by Hibernate is required to
have a default constructor with at least package scope. They should have get and set methods
for all of the attributes that are to be persisted. We will provide each with an id field, allowing
this to be the primary key in our database (we prefer the use of surrogate keys, as changes to
business rules can make the use of direct keys risky).
Search WWH ::




Custom Search