Persistent classes are classes in an application that implement the entities of the business problem (e.g. Customer and Order in an E-commerce application). Persistent classes have, as the name implies, transient and also persistent instance stored in the database. Hibernate works best if these classes follow some simple rules, also known as the Plain Old Java Object (POJO) programming model. Most Java applications require a persistent class representing felines. There are four main rules to follow here: Cat declares accessor methods for all its persistent fields. Many other ORM tools directly persist instance variables. We believe it is far better to decouple this implementation detail from the persistence mechanism. Hibernate persists JavaBeans style properties, and recognizes method names of the form getFoo, isFoo and setFoo. Properties need not be declared public - Hibernate can persist a property with a default, protected or private get / set pair. Cat has an implicit default (no-argument) constructor. All persistent classes must have a default constructor (which may be non-public) so Hibernate can instantiate them using Constructor.newInstance(). Cat has a property called id. This property holds the primary key column of a database table. The property might have been called anything, and its type might have been any primitive type, any primitive "wrapper" type, java.lang.String or java.util.Date. (If your legacy database table has composite keys, you can even use a user-defined class with properties of these types - see the section on composite identifiers below.) The identifier property is optional. You can leave it off and let Hibernate keep track of object identifiers internally. However, for many applications it is still a good (and very popular) design decision. What's more, some functionality is available only to classes which declare an identifier property: Cascaded updates (see "Lifecycle Objects") Session.saveOrUpdate() We recommend you declare consistently-named identifier properties on persistent classes. We further recommend that you use a nullable (ie. non-primitive) type. A central feature of Hibernate, proxies, depends upon the persistent class being either non-final, or the implementation of an interface that declares all public methods. You can persist final classes that do not implement an interface with Hibernate, but you won't be able to use proxies - which will limit your options for performance tuning somewhat. A subclass must also observe the first and second rules. It inherits its identifier property from Cat. You have to override the equals() and hashCode() methods if you intend to mix objects of persistent classes (e.g. in a Set). This only applies if these objects are loaded in two different Sessions, as Hibernate only guarantees JVM identity ( a == b , the default implementation of equals()) inside a single Session! Even if both objecs a and b are the same database row (they have the same primary key value as their identifier), we can't guarantee that they are the same Java instance outside of a particular Session context. The most obvious way is to implement equals()/hashCode() by comparing the identifier value of both objects. If the value is the same, both must be the same database row, they are therefore equal (if both are added to a Set, we will only have one element in the Set). Unfortunately, we can't use that approach. Hibernate will only assign identifier values to objects that are persistent, a newly created instance will not have any identifier value! We recommend implementing equals() and hashCode() using Business key equality. Business key equality means that the equals() method compares only the properties that form the business key, a key that would identify our instance in the real world (a natural candidate key): Keep in mind that our candidate key (in this case a composite of name and birthday) has to be only valid for a particular comparison operation (maybe even only in a single use case). We don't need the stability criteria we usually apply to a real primary key! Optionally, a persistent class might implement the interface Lifecycle which provides some callbacks that allow the persistent object to perform necessary initialization/cleanup after save or load and before deletion or update. The Hibernate Interceptor offers a less intrusive alternative, however. onSave - called just before the object is saved or inserted onUpdate - called just before an object is updated (when the object is passed to Session.update()) onDelete - called just before an object is deleted onLoad - called just after an object is loaded onSave(), onDelete() and onUpdate() may be used to cascade saves and deletions of dependent objects. This is an alternative to declaring cascaded operations in the mapping file. onLoad() may be used to initialize transient properties of the object from its persistent state. It may not be used to load dependent objects since the Session interface may not be invoked from inside this method. A further intended usage of onLoad(), onSave() and onUpdate() is to store a reference to the current Session for later use. Note that onUpdate() is not called every time the object's persistent state is updated. It is called only when a transient object is passed to Session.update(). If onSave(), onUpdate() or onDelete() return true, the operation is silently vetoed. If a CallbackException is thrown, the operation is vetoed and the exception is passed back to the application. Note that onSave() is called after an identifier is assigned to the object, except when native key generation is used. If the persistent class needs to check invariants before its state is persisted, it may implement the following interface: The object should throw a ValidationFailure if an invariant was violated. An instance of Validatable should not change its state from inside validate(). Unlike the callback methods of the Lifecycle interface, validate() might be called at unpredictable times. The application should not rely upon calls to validate() for business functionality. In the next chapter we will show how Hibernate mappings may be expressed using a simple, readable XML format. Many Hibernate users prefer to embed mapping information directly in sourcecode using XDoclet @hibernate.tags. We will not cover this approach in this document, since strictly it is considered part of XDoclet. However, we include the following example of the Cat class with XDoclet mappings.