井上 研一 いつもハロプロ系の記事ばかり書いておりますが、たまには別のことを。
本職はWebシステムを作っているSEです。ということで、Hibernateのことを書いてみよう！と思います。
ここから先は、技術ネタで飛ばして行きますので、よろしく。
１．まず、Hibernateについて
オブジェクト指向をやっている技術者というのは、いつも永続化について悩むものです。
どんな問題があったとしても、永続化を上回る問題というのは、そうはありません。
私は、たまにオブジェクト指向の講師というやつを社内でやります。そこで永続化に関する説明はどうやるかというと…。
システム化対象業務をオブジェクトモデルとして、メモリ上に構成します。
メモリというのは電源を切ると消えますから、何とかして電源とは関係なく残しておかなければなりません。
で、どうするかというと、1つは、電源を切っても記録が消えないメモリを使えばいいんですね。
これで解決です。
…、え？ダメ？じゃぁ、ファイルにしましょう。システム終了時にメモリの中身をファイルに移して、次のシステム起動時にファイルからメモリに書き戻せば良いですね。
でも、それだとデータ量が多いと、メモリの量が大変なことになります。
じゃぁ、やっぱり必要な時だけオブジェクトを復元して、いらなくなったらディスクに移してやるということが必要になります。
ま、データベースということになりますが、オブジェクト指向データベースというやつがあります。
なかなか便利だと思います。でも、なかなかお客様先で採用されないですね。
やっぱり、Oracleを使いたいだろうし、DB2かもしれないし、MySQLかもしれないけど、結局、リレーショナルデータベース（RDB）を使いたいわけです。
…てな具合です。
しかし、オブジェクトモデルと、RDBにはインピーダンスギャップがあります。
そのままに、右に左にとは移せない関係なのです。
その間を上手く取り持ってくれるもの、それがORマッパといわれるものです。
そして、ORマッパのデファクトスタンダード（と言って構わないでしょう）が、Hibernateです。
２．ちょっと、おさらい
ところで、アプリケーションがRDBにアクセスする戦略を復習しておきます。
（１）ResultSetを操作する
JDBC経由でSQLを投げて、返ってきたResultSetを操作するという方式です。
最も古典的で単純な方法。
ちょっとイカしたJava開発なら、もう、この方法は使わないでしょう。
（２）DAO（Data Access Object）を使う
テーブル単位にINSERT、UPDATE、DELETE、SELECTするメソッドを集めたDAOを設けて、アプリケーションからはDAO経由でのみRDBを操作するというものです。
ポイントは、アプリケーションが直接SQLを投げないこと、ResultSetも直接操作せずDAOとのやり取りはJavaBeans（1テーブル＝1JavaBeans）で行うということです。
SeasarファウンデーションのS2Daoや、Jakarta CommonsのDbUtilsを使うと、簡単に実装できます。
（３）ORマッパを使う
基本的に1テーブルを1JavaBeansにマッピングすることは、DAOと同じです。
しかし、ORマッパでは、テーブル単位のDAOは存在しません。
関連を持った複数のオブジェクト（JavaBeans）を、そのまま取り扱うことが出来ます。
ある程度の塊になったオブジェクトモデルを、そのまま、RDBに保存したり、RDBから取り出すことが出来ます。
DAOとORマッパについては、未だ、どちらが良いのか、評価が定まらないようです。（おそらく、それは永続化以外の領域で、設計方法論にまで話が及ぶからです。）
実際のプロジェクトにおいては、オブジェクト指向を採用した度合いによって、良し悪しが決まるのではないでしょうか。
結局、その程度が強くなければDAOで良いし、DAOで対応できる範囲を超えるようなら、ORマッパを使うしかないでしょう。
基本的には、DAOの方が軽量で簡単なのです。（ORマッパになることを否定しているS2Daoの機能を見ると、Seasar2っぽいなと思います。）