Chapter 3. Working with Java Persistence and Entities

In this chapter, we will develop the following recipes:

  • Configuring the Java Persistence API (JPA) in Spring
  • Defining useful EJB3 entities and relationships
  • Making use of the JPA and Spring Data JPA

Introduction

The Java Persistence API (JPA) is a specification that has been produced in different releases from 2006 (JPA 1.0) to 2013 (JPA 2.1) by a group of various experts. Historically, it is one of the three pieces of the EJB 3.0 specification, which has come along with JEE5.

More than an upgrade of Enterprise JavaBeans (EJB), JPA was pretty much a complete redesign. At the time, the leading providers of Object Relational Mapping solution (such as Hibernate) and of J2EE application servers (such as WebSphere, JBoss) have been involved, and the global result has been unarguably simpler. All the types of EJBs (stateful, stateless, and entities) are now simple Plain Old Java Objects (POJOs) that are enriched with specific metadata that is nicely presented as annotations.

The Entities' benefits

Entities play a key role in the EJB3 model. As simple POJOs, they can be used in every single layer of the application.

Ideally, an entity represents an identifiable functional unit within a business domain. The norm is to make an entity representing a database table row. As simple POJOs, entities can rely on inheritance (the IS-A relationship) and can have attributes (the HAS-A relationship), just as a database schema is normally be described with. Through these relationships, an entity establishes connections with other Entities. These connections are described with @Annotations, which make the entity metadata.

An entity must be seen as the application-equivalent element of a database table row. JPA allows to operate this element and its whole ecosystem as a Java object hierarchy and to persist it as such.

Entities have brought an amazing radicalization of the persistence layer (by decreasing the number of hardcoded SQL queries to be maintained), and also the simplification of the service and transformation layers. Being able to pass through all the levels (they are used even in views), they dramatically drive the domain-specific names and concepts used within the application (methods, classes, and attributes). They indirectly focus on the essentials, and impose consistency between application concepts and database concepts.

It is obviously a plus to have a solid and well-thought schema from the beginning.

Note

JPA brings amazing performance and maintainability results on UI applications. However, it may not always suit performance expectations if it is used to accomplish batches or bulk database operations. It can sometimes be sensible to instead consider direct JDBC accesses.

The Entity manager and its persistence context

We have seen that an entity can have relations with other entities. In order for us to be able to operate on an entity (read from a database, update, delete, and persist), there is a background API that generates the preparation of SQL queries. This API in a persistence provider (Hibernate, Toplink, and so on) is the EntityManager. Once it loads the object for the purpose of the application, we can trust it to manage its life cycle.

There are a couple of concepts attached to the EntityManager that we need to review before moving forward. An entity is managed once the EntityManager gets an instance of it from a database read (explicit or implicit). The JPA persistence context is formed by the conceptual aggregation of the whole set of managed entities. A persistence context will always carry no more than one instance of an entity discriminated by its identifier (@Id or a unique ID class).

If, for some reason, an entity is not managed, it is said to be detached (understand detached from the persistence context).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset