2006年01月12日

C. Bauer、G. King『Hibernate イン アクション』

 1年ほど前にJavaのORM(O/R マッピング)を調べた。そのときから、一番人気はHibernateだった。が、私は大いに気に入らなかった。
 気に入らない点はいくつもあったが、なんといっても、「POJO」というバズワードだ。このバズワードは、臭う。かつて「has-a」だの「is-a」だのをこねくりまわしていた連中の匂いがする。
 POJO党はコンテナ問題を持ち出すのが好きだ。いわく、コンテナ内でしか動作しないコードは、単体テストに時間がかかるのでよくない。だが、コンテナに依存しないこととPOJOであることは、まったくの別問題だ。コンテナの起動は時間がかかるので、コンテナへの依存性は最小限にしたいのは事実だ。しかし、永続化クラスに親クラスがないのが利点とは思えない。
 (Cayenneの永続化クラスはCayenneDataObjectを継承しているが、コンテナのようなものは必要としない。引数のないコンストラクタでnewすることもできる)
 POJO党は継承(特に多重継承)を嫌い、リフレクションを好む。私にいわせれば、リフレクションはsynchronizedやvolatileと同じくらい危険だ。世界のどこかには必要だが、可能な限り遠ざけておくべきものだ。
 (CayenneはJavaのコードをツールで自動生成することでリフレクションを避けている)
 『Hibernate イン アクション』を読んで、私はさらに論拠を得た。
 筆者は、ORMのR(RDB)の部分を優先すべきだという。それと同時に、永続化クラス間に継承関係をつけられることを強調する。矛盾だ。よほど特定のRDBMSが好きなプログラマでもないかぎり、RDBのテーブル設計に継承などという概念は持ち込まない。
 Hibernateの面倒くささは、この矛盾に端を発している。まるで、O側とR側にそれぞれ別のプログラマがいて、どちらも自分の設計を譲らない、という状態を想定しているかのようだ。
 こんな状態を想定すること自体が間違っている。O側が譲るべきだ。さもなければOODBMSを採用すべきだ。データ構造とロジックでは、データ構造が上だ。
 Javaは、委員会が設計した言語としては、史上初めての成功を収めつつある。委員会の呪いは、どこへ行ってしまったのだろう?――おそらくは、EJBへ。EJBにかけられた呪いときたら、並の委員会20個からそれぞれ代表を送って「委員会についての委員会」を作ったかと思われるほどだ。
 EJB 3.0の永続化はHibernate風になるらしい。おそらく、今から3年後には、Hibernate風の永続化への呪いが世に満ちるだろう。7andy

Posted by hajime at 2006年01月12日 03:50
Comments