Hibernate アーキテクチャの(非常に)高いレベルからのビュー:
この図は Hibernate が、アプリケーションに対して永続化サービス (と永続オブジェクト)を提供するために、データベースと設定データを使うことを示しています。
ここで実行時アーキテクチャのより詳細なビューをお見せしましょう。あいにく、 Hibernate は柔軟であり、いろいろなアプローチをサポートしています。ここでは、2つの極端な例をお見せします。「軽い」アーキテクチャでは、アプリケーションが自前の JDBC コネクションを用意し、アプリケーション自身がトランザクションを管理します。この方法は、 Hibernate API の最小限のサブセットを使います:
「軽い」アーキテクチャは、アプリケーションから、その下に位置する JDBC や JTA の API を取り払って抽象化し、その詳細の面倒を Hibernate に見させます。
以下は、図に含まれるオブジェクトの定義です:
org.hibernate.SessionFactory)
1つのデータベースに対するコンパイルされたマッピングのスレッドセーフな(更新不能の)キャッシュ。 Session のファクトリであり、 ConnectionProvider のクライアント。オプションとして、プロセスまたはクラスタレベルにおいて、トランザクション間で再利用可能なデータの(二次)キャッシュを持ちます。
org.hibernate.Session)
アプリケーションと永続ストアとの対話を表す、シングルスレッドで短命のオブジェクト。 JDBC コネクションをラップします。 Transaction のファクトリです。永続オブジェクトの必須の(一次)キャッシュを保持します。このキャッシュはオブジェクトグラフをナビゲーションする時や、識別子でオブジェクトを検索する時に使われます。
永続化状態とビジネス機能を持つ、短命でシングルスレッドのオブジェクト。これは通常の JavaBeans/POJO のこともありますが、特徴的なことは、その時点での(ただ1つの) Session と関連していることです。 Session がクローズされるとすぐに、それらは切り離されて他のアプリケーション層から自由に使うことができます(例えばデータトランスファオブジェクトとして、プレゼンテーション層から、またはプレゼンテーション層へ直接使用できます)。
現時点では Session と関連していない、永続クラスのインスタンス。すでにアプリケーション側でインスタンス化されていて、まだ永続化されていないか、クローズされた Session でインスタンス化されたかのどちらかです。
org.hibernate.Transaction)
(オプション) 原子性を持つ作業単位 (Unit of Work) を指定するために、アプリケーションが使用する、シングルスレッドで短命なオブジェクト。下に位置する JDBC 、 JTA 、 CORBA トランザクションからアプリケーションを抽象化します。 Session は、時にはいくつかの Transaction をまたがるかもしれません。しかし、下の層の API を使うにせよ、 Transaction を使うにせよ、トランザクション境界を設定することは、決してオプションではありません。
org.hibernate.connection.ConnectionProvider)
(オプション) JDBC コネクション(とそのプール)のファクトリ。下の層に位置する Datasource や DriverManager からアプリケーションを抽象化します。アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
org.hibernate.TransactionFactory)
(オプション) Transaction インスタンスのファクトリ。アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
Hibernate は、永続層の振る舞いをカスタマイズするために、多くのオプション拡張インタフェースを用意しています。詳細は API ドキュメントを参照してください。
「軽い」アーキテクチャでは、アプリケーションは直接 JTA や JDBC と対話するために、 Transaction や TransactionFactory や ConnectionProvider の API をバイパスします。