ほとんどのJavaアプリケーションにはネコ科の動物を表現する永続クラスが必要です。

package eg;
import java.util.Set;
import java.util.Date;

public class Cat {
    private Long id; // identifier

    private Date birthdate;
    private Color color;
    private char sex;
    private float weight;
    private int litterId;

    private Cat mother;
    private Set kittens = new HashSet();

    private void setId(Long id) {
        this.id=id;
    }
    public Long getId() {
        return id;
    }

    void setBirthdate(Date date) {
        birthdate = date;
    }
    public Date getBirthdate() {
        return birthdate;
    }

    void setWeight(float weight) {
        this.weight = weight;
    }
    public float getWeight() {
        return weight;
    }

    public Color getColor() {
        return color;
    }
    void setColor(Color color) {
        this.color = color;
    }

    void setSex(char sex) {
        this.sex=sex;
    }
    public char getSex() {
        return sex;
    }

    void setLitterId(int id) {
        this.litterId = id;
    }
    public int getLitterId() {
        return litterId;
    }

    void setMother(Cat mother) {
        this.mother = mother;
    }
    public Cat getMother() {
        return mother;
    }
    void setKittens(Set kittens) {
        this.kittens = kittens;
    }
    public Set getKittens() {
        return kittens;
    }
    
    // addKitten not needed by Hibernate
    public void addKitten(Cat kitten) {
        kitten.setMother(this);
        kitten.setLitterId( kittens.size() ); 
        kittens.add(kitten);
    }
}

従うべき4つのルールがあります：

サブクラスも1番目と2番目のルールを守らなければなりません。 サブクラスはスーパークラス Cat から識別子プロパティを継承します。

package eg;

public class DomesticCat extends Cat {
        private String name;

        public String getName() {
                return name;
        }
        protected void setName(String name) {
                this.name=name;
        }
}

以下の条件の場合、 equals() と hashCode() メソッドをオーバーライドしなければなりません、

Hibernateは、永続ID（データベースの行）と、特定のセッションスコープ内に 限定ですがJavaIDとが等価であることを保証します。 ですから異なるセッションで検索したインスタンスを組み合わせる場合、 Set に意味のあるセマンティクスを持たせようと思っているなら すぐにequals() と hashCode() を実装しなければなりません。

最も明白な方法は、両方のオブジェクトの識別子の値の比較によって equals()と hashCode() を実装する方法です。 値が同じなら、両者はデータベースの同じ行でなければならないため等しくなります。 （両者が Set に追加されても、 Set には1個の要素しかないことになります） 残念なことに、生成された識別子にはこのアプローチを使うことができません。 Hibernateは永続化されたオブジェクトへ識別子の値を代入するだけであり、 新しく作成されたインスタンスはどのような識別子の値も持っていません。 さらに、インスタンスがセーブされておらず、現在 Set の中にあれば、 セーブするとオブジェクトへ識別子の値を代入することになります。 もし equals() と hashCode() が識別子の値に基づいているなら、 ハッシュコードが変更されると Set の規約が破られます。 この問題についての完全な議論は、Hibernateのウェブサイトを見てください。 これはHibernateの問題ではなく、オブジェクトの同一性と等価性についての、 通常のJavaのセマンティクスであることに注意してください。

ビジネスキーの等価性 を使って、 equals() と hashCode() を実装することをお勧めします。 ビジネスキーの等価性とは、equals() メソッドが、ビジネスキー、 つまり現実の世界においてインスタンスを特定するキー（自然 候補キー） を形成するプロパティだけを比較することを意味します。

public class Cat {

    ...
    public boolean equals(Object other) {
        if (this == other) return true;
        if ( !(other instanceof Cat) ) return false;

        final Cat cat = (Cat) other;

        if ( !cat.getLitterId().equals( getLitterId() ) ) return false;
        if ( !cat.getMother().equals( getMother() ) ) return false;

        return true;
    }

    public int hashCode() {
        int result;
        result = getMother().hashCode();
        result = 29 * result + getLitterId();
        return result;
    }

}

ビジネスキーはデータベースの主キー候補ほど安定である必要はないことに注意してください （項11.1.3. 「オブジェクト識別子を考える」 を見てください）。 更新不可なプロパティやユニークなプロパティは、通常ビジネスキーのよい候補です。

以下の機能は現在実験段階にあると見なされており、 近い将来変更される可能性があることに注意してください。

永続エンティティは、必ずしも実行時にPOJOクラスやJavaBeanオブジェクトで表現する必要はありません。 Hibernateは（実行時に Map の Map を使う）動的モデルと、 DOM4Jツリーとしてのエンティティの表現もサポートします。 このアプローチを使うと永続クラスを書かず、マッピングファイルだけを書くことになります。

デフォルトでは、Hibernateは通常のPOJOモードで動作します。 default_entity_mode 設定オプションを使って、 特定の SessionFactory に対するデフォルトのエンティティ表現モードを設定することができます （表 3.3. 「Hibernate設定プロパティ」 を見てください）。

以下の例では Map を使った表現を紹介します。 まずマッピングファイルで、クラス名の代わりに（またはそれに加えて） entity-name を定義しなければなりません：

<hibernate-mapping>

    <class entity-name="Customer">

        <id name="id"
            type="long"
            column="ID">
            <generator class="sequence"/>
        </id>

        <property name="name"
            column="NAME"
            type="string"/>

        <property name="address"
            column="ADDRESS"
            type="string"/>

        <many-to-one name="organization"
            column="ORGANIZATION_ID"
            class="Organization"/>

        <bag name="orders"
            inverse="true"
            lazy="false"
            cascade="all">
            <key column="CUSTOMER_ID"/>
            <one-to-many class="Order"/>
        </bag>

    </class>
    
</hibernate-mapping>

関連がターゲットのクラス名を使って定義していたとしても、 関連のターゲット型もPOJOではなく動的なエンティティでも構わないことに注意してください。

SessionFactory に対してデフォルトのエンティティモードを dynamic-map に設定した後、 実行時に Map の Map を使うことができます：

Session s = openSession();
Transaction tx = s.beginTransaction();
Session s = openSession();

// Create a customer
Map david = new HashMap();
david.put("name", "David");

// Create an organization
Map foobar = new HashMap();
foobar.put("name", "Foobar Inc.");

// Link both
david.put("organization", foobar);

// Save both
s.save("Customer", david);
s.save("Organization", foobar);

tx.commit();
s.close();

動的なマッピングの利点は、エンティティクラスの実装を必要としないため、 プロトタイピングに要するターンアラウンドタイムが早いということです。 しかしコンパイル時の型チェックがないので、実行時に非常に多くの例外処理を扱わなければならないでしょう。 Hibernateマッピングのおかげで、データベーススキーマは容易に正規化でき、健全になり、 後で適切なドメインモデルの実装を追加することが可能になります。

エンティティ表現モードは Session ごとに設定することも可能です。

Session dynamicSession = pojoSession.getSession(EntityMode.MAP);

// Create a customer
Map david = new HashMap();
david.put("name", "David");
dynamicSession.save("Customer", david);
...
dynamicSession.flush();
dynamicSession.close()
...
// Continue on pojoSession

EntityMode を使った getSession() の呼び出しは SessionFactory ではなく Session APIにあることに注意してください。 その方法では、新しい Session は、ベースとなるJDBCコネクション、 トランザクション、その他のコンテキスト情報を共有します。 これは2番目の Session では flush() と close() を呼ぶ必要がないということ、そのためトランザクションとコネクションの管理を 1番目の作業単位(Unit of Work)に任せることができるということです。

XML表現の能力についてのさらなる情報は 章 18. XMLマッピング で見つかります。

org.hibernate.tuple.Tuplizer とそのサブインターフェイスは、 表現の org.hibernate.EntityMode を利用して、 データ断片のある表現の管理に責任を持ちます。 与えられたデータ断片をデータ構造として考えるなら、Tuplizerはそのようなデータ構造を どのように作成するかを知り、そのようなデータ構造からどのように値を抽出し、 注入するかを知っています。 例えばPOJOエンティティモードでは、対応するTuplizerはコンストラクタを通して、 POJOをどのように作成するか、定義されたプロパティアクセサを使い、 POJOプロパティにどのようにアクセスするかを知ります。 Tuplizerには二つのハイレベルの型があります。 それらは、org.hibernate.tuple.EntityTuplizer と org.hibernate.tuple.ComponentTuplizer インターフェイスで表現されます。 EntityTuplizer は上で述べたようなエンティティに関する契約の管理に責任を持ちます。 一方、ComponentTuplizer はコンポーネントに関する契約の管理に責任を持ちます。

ユーザは独自のTuplizerに差し替えることも可能です。 おそらくdynamic-map entity-modeの際に java.util.HashMap を使うのではなく、 java.util.Map の実装が必要でしょう。 もしくは、おそらくデフォルトのものではなく、別のプロキシ生成戦略の定義が必要でしょう。 両者とも、カスタムのTuplizer実装を定義することで達成されます。 Tuplizerの定義は、管理しようとするエンティティやコンポーネントのマッピングに結び付けられます。 顧客エンティティの例に戻ると：

<hibernate-mapping>
    <class entity-name="Customer">
        <!--
            Override the dynamic-map entity-mode
            tuplizer for the customer entity
        -->
        <tuplizer entity-mode="dynamic-map"
                class="CustomMapTuplizerImpl"/>

        <id name="id" type="long" column="ID">
            <generator class="sequence"/>
        </id>

        <!-- other properties -->
        ...
    </class>
</hibernate-mapping>


public class CustomMapTuplizerImpl
        extends org.hibernate.tuple.entity.DynamicMapEntityTuplizer {
    // override the buildInstantiator() method to plug in our custom map...
    protected final Instantiator buildInstantiator(
            org.hibernate.mapping.PersistentClass mappingInfo) {
        return new CustomMapInstantiator( mappingInfo );
    }

    private static final class CustomMapInstantiator
            extends org.hibernate.tuple.DynamicMapInstantitor {
        // override the generateMap() method to return our custom map...
        protected final Map generateMap() {
            return new CustomMap();
        }
    }
}