What is a persistence object?

Question

I am reading the Java EE Tutorial and here I see this sentence in the begining:

An entity is a lightweight persistence domain object.

I have searched for persistence object but could not find a clear explanation.

What exactly is a persistence domain object ?

Answer 1

I just add this answer related to another question of Koray Tugay.

In Java EE a JPA entity is typically a Bean managed by the JPA Container. This container is provided in any Java EE certified application server.

Each entity Object is an in-memory representation of the state of one or more table in a RDBMS instance. Every state modification of a managed entity within a transaction will be automatically handled by the container and mapped as sql order executed against the database. So you don't have to care about the persistence part of your domain model. Just modify the corresponding Java objects (entities) state and it will be automatically reflected to the database. (Of course this is not magic and comes with its own pitfalls.)

Every entity is part of a persistence unit associated to a datasource for which a connection pool is provided.

A persistence unit is managed by many EntityManager instances. The EntityManager is in charge of managing an in memory representation of all entities of the associated persistence unit; At least the ones that are currently loaded from the database. You usually have one EntityManager instance per thread (~ per http request).

When using a container-managed EntityManager (means injected with @PersistenceContext), the container will automatically propagate for you the transaction context between all the beans (controller / services / dao / etc...) implied in the persistence unit manipulation.

(last sentence means it will open a transaction when encountering a @transactionnal annotation and every method on any bean executed during the current method call will be part of the same transaction. The transaction will be committed (or rolled back) at the end of the method execution).

Answer 2

Java EE assumes something called a Domain Model. The domain model consists of objects representing entities, where an Entity is something that has an identity relevant to the business. (For example, if you work at a bank your domain might involve things like Accounts, Customers, Holdings, and Loans).

Here is a quote from Bauer and King's Java Persistence with Hibernate describing domain models:

3.1.1. Analyzing the business domain

A software development effort begins with analysis of the problem domain (assuming that no legacy code or legacy database already exists).

At this stage, you, with the help of problem domain experts, identify the main entities that are relevant to the software system. Entities are usually notions understood by users of the system: payment, customer, order, item, bid, and so forth. Some entities may be abstractions of less concrete things the user thinks about, such as a pricing algorithm, but even these would usually be understandable to the user. All these entities are found in the conceptual view of the business, which we sometimes call a business model. Developers and architects of object-oriented software analyze the business model and create an object-oriented model, still at the conceptual level (no Java code). This model may be as simple as a mental image existing only in the mind of the developer, or it may be as elaborate as a UML class diagram created by a computer-aided software engineering (CASE) tool like ArgoUML or TogetherJ. A simple model expressed in UML is shown in figure 3.1.

This model contains entities that you're bound to find in any typical auction system: category, item, and user. The entities and their relationships (and perhaps their attributes) are all represented by this model of the problem domain. We call this kind of object-oriented model of entities from the problem domain, encompassing only those entities that are of interest to the user, a domain model. It's an abstract view of the real world.

The motivating goal behind the analysis and design of a domain model is to capture the essence of the business information for the application's purpose.

Ideally (in an approach called Domain-Driven Design) these domain objects have 2 features: they do not know about infrastructure concerns like persistence or transactions, and they contain logic implementing the state transitions that occur when they are manipulated during the course of business processing; the combination of these means that business logic can be tested separately from infrastructure. In the real world it's more typical to see anemic domain objects which do not contain any business logic, the business logic all ends up in transaction scripts.

Anyway the idea is you have a domain model made up of persistent entities. There is some kind of configuration (annotations or XML files or whatever) which maps the entities and their attributes to tables and columns in a database, and which maps the relationships between the entities. There's an Object-Relational Mapper (JPA is a standard for implementing ORMs, Hibernate is one such implementation) that knows how to convert the data back and forth between the database representation and the object-graph representation, so that the developer can manipulate objects instead of database rows.

For people who claim that business logic should not be part of the domain model, here is another quote from the Java Persistence with Hibernate book, in section 3.1.2:

The entities in a domain model should encapsulate state and behavior. For example, the User entity should define the name and address of a customer and the logic required to calculate the shipping costs for items (to this particular customer). The domain model is a rich object model, with complex associations, interactions, and inheritance relationships. An interesting and detailed discussion of object-oriented techniques for working with domain models can be found in Patterns of Enterprise Application Architecture (Fowler, 2003) or in Domain-Driven Design (Evans, 2003).

In this book, we won't have much to say about business rules or about the behavior of our domain model. This isn't because we consider it unimportant; rather, this concern is mostly orthogonal to the problem of persistence. It's the state of our entities that is persistent, so we concentrate our discussion on how to best represent state in our domain model, not on how to represent behavior. For example, in this book, we aren't interested in how tax for sold items is calculated or how the system may approve a new user account. We're more interested in how the relationship between users and the items they sell is represented and made persistent. We'll revisit this issue in later chapters, whenever we have a closer look at layered application design and the separation of logic and data access.

So apparently the Hibernate developers see it as a viable alternative, although it doesn't seem to be a common approach in typical enterprise development.

Answer 3

Its a state of a Domain object.

a persistent instance has a representation in the database and an identifier value. It might just have been saved or loaded, however, it is by definition in the scope of a Session.

For example see the states of objects here in java ORM framework hibernate

disclaimer:this is just for an idea.