JPA entities - EJB 3 in Action - page 338

JavaBeans
JavaBeans rules state that all objects have a no-argument constructor and that instance vari-
ables should be nonpublic and made accessible via methods that follow the getXX and
setXX pattern used in listing 9.1 , where XX is the name of the property (instance variable).
The Category class as it stands in listing 9.1 is a perfectly acceptable Java implementa-
tion of a domain object. The problem is that it's still just a POJO. There's currently no way
of distinguishing the fact that the Category class should be managed by JPA. There's
also nothing that tells JPA how the Category class should be managed. For example, JPA
has no idea the id property holds the unique identifier for the Category . Also, the rela-
tionship properties ( items , subCategories ) don't specify direction or multiplicity for
the relationship. Next, you'll start solving some of these problems by updating the POJO
with JPA annotations, starting with identifying the Category class as a domain object.
9.3. Implementing domain objects with JPA
In the previous sections you learned about domain modeling concepts and identified part
of the ActionBazaar domain model. In this section, you'll see some of the JPA annota-
tions in action as you implement part of the domain model using JPA. We'll start with the
@Entity annotation that converts any POJO to an entity manageable by JPA. Then you'll
learn about field- and property-based persistence and entity identity. Finally, we'll discuss
embedded objects.
9.3.1. @Entity annotation
The @Entity annotation marks a POJO domain object as an entity that can be managed
by JPA. You may think of the @Entity annotation as the persistence counterpart of
the @Stateless , @Stateful , and @MessageDriven annotations. Mark the Cat-
egory class as an entity as follows:
@Entity
public class Category {
//...
public Category() { /**/ }
public Category(String name) { /**/ }