hibernate

さて、このシリーズの主役はHibernateです。

１．お題

今回は、このようなドメインモデルを使います。
大学通信教育の履修管理システムです。
どの科目を、いつから勉強を始めて、いつレポートを出して、単位修得試験を受験して、それぞれの評価はどうで、単位をいくつ取ったか…ということを管理します。
クラスが5つ。関連は1対1と、1対多の2種類があります。
Hibernateのサンプルとしては、継承がないのが残念ですが、これは後でいくらでも拡張できるでしょう。
例えば、Subject（科目）には、必修／選択必修／選択とか、一般教育科目／専門教育科目などの種類があります。継承のネタにはなりそうです。
今回は、初歩のサンプルですから、これで行きます。

２．Hibernateを使うためのアプローチ

Hibernateを使うためには、いくつかのモノが必要です。
まず、Hibernate自体の設定ファイルが必要です。
何らかのドメインモデルを、Hibernateを使って永続化するには、ドメインオブジェクト（もしくはテーブル）毎に、以下の種類のモノが必要となります。

• JavaBeans（Study.class）
• マッピングファイル（Study.hbm.xml）
• RDBテーブル（Studyテーブル）

ところで、この3つのうち、何からどうやって作っていくか…には、いくつかのアプローチがあります。

（１）ドメインモデルありき
つまりJavaBeansはあるので、それを元にテーブルとマッピングファイルを作っていきます。これを、Top-Downアプローチと言います。
とても、オブジェクト指向な感じですね。
このアプローチなら、XDocletでJavaBeansからマッピングファイルを作り、Hibernateの機能でマッピングファイルからテーブルを作ることが出来ます。

（２）テーブルありき
テーブルは既にあるから、それを元にJavaBeansとマッピングファイルを作ります。これを、Bottom-Upアプローチと言います。
多くの開発プロジェクトは、これになりそうな気がします。
このアプローチなら、Middlegenというツールを使って作業を自動化できます。

（３）マッピングファイルから作ろう！
逆説的な気もしますが、マッピングファイルを先に作ります。そこから、JavaBeansとテーブルを作っていきます。これを、Middle-Outアプローチと言います。
「マッピングファイル＝Hibernateで出来ること」ですから、Hibernateを骨の髄までしゃぶるなら、これかもしれません。
定義がしっかりしているだけに、このアプローチをベースにした、開発ツールとか作れそうですね。

（４）マッピングファイルを作ることが面倒だ！
JavaBeansもテーブルもある。しかし、マッピングファイルだけない。だから、最後にマッピングファイルを作ろうというもの。これを、Meet-in-Middleアプローチと言います。
顧客にはテーブルで説明しないといけない、でも設計はオブジェクト指向で進んでいる…中途半端だけど、最もありそうなケースかもしれません。

今回は、既にドメインモデルがありますから、Top-Downアプローチを採ります。また、敢えてツールは使わず、手作業で進めます。

「Hibernateをいじる（３）」につづく

いつもハロプロ系の記事ばかり書いておりますが、たまには別のことを。
本職は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っぽいなと思います。）

「Hibernateをいじる（２）」につづく

Seasar2に続き、Hibernate3を試してみました。

公式サイトのマニュアルと、バージョンは違うものの@ITの記事「Hibernateで理解するO/Rマッピング」を参考に、昨日、S2DAOで実験したGroupUnitとMemberの簡単なモデルで実験。

公式サイトのマニュアル（英語ですが）のサンプルソースを参考に、JavaBeansを2つ（GroupUnitとMember）、マッピングファイル、Hibernateの設定ファイルを作成。
それで・・・、

• 単純なGroupのInsert
• 単純なGroupのSelect（List）
• N:1関連のSelect
• Groupを持つMemberのInsert
• 1:N関連のSelect
• Memberが持っているGroupを変更後Update

といった内容の実験を行いました。

細かい部分の実験はやっていませんが、上記のシンプルな実験は、すべて成功。
お手軽なS2DAOと違ってきちんとしたマッピングファイルが必要になりますが、その分、機能は充実しています。1:N関連がサポートされているし、Groupを持つMemberのInsertの件も、RDB上での外部KEYを意識することなく（マッピングファイルには書く必要がありますが、プログラムでは意識不要）、対応できます。カッコイイ。

Updateの実験では、トランザクションの実験を兼ねてみました。これもcommit、rollbackとも整然と動いてくれます。ただ、rollbackしても同じSession内だと、Query使って再取得してもrollbackされていませんね。別Sessionにすると、ちゃんとrollbackされた内容が反映されます。

おそらく、マッピングファイルが肝だなぁと思いました。この文法がきっとHibernateで出来ることのすべてなんだろうし、真のOOD、OOPをやるために必要な機能は、おそらくすべて揃っているのだろうし・・・。全体の把握はなかなか大変でしょうが、把握しなければうまく使えないのではないかと。

昨日のS2DAOといい、今日のHibernateといい、永続化部分の実装を全部人間がやるのは、いまやナシなんだなと実感しました。

あと、公式サイトの設定ファイルサンプルをそのままコピペすると、動かすたびにDROP TABLEとCREATE TABLEされます。マッピングファイルからDDLを作れるわけですが、勝手にテーブルを消したり作ったりまでやっちゃいます。実験用のサンプルだからでしょうが、コピペするだけで中身を見ないと、ハマります。ご注意を。