次に、開発効率面での懸念について検討したいと思います。本連載中ではHibernateをいくつか取り上げてきました。CMPを実装した経験のある方であれば、CMPに比べて非常に簡単に実装およびデプロイができることを実感できたと思います。しかし、それはCMPが重厚な仕組みを持つために多くの記述を求めていたことで、相対的にHibernateの実装の方が簡単に思えるだけではないでしょうか。
CMPを実装した経験がない方で、本連載中のサンプルを作成してみた方はPOJOやマッピングファイルの定義を記述するときに「面倒だ」と感じられたかもしれません。1度記述したマッピングファイルを見ながら、もう一度同じようにPOJOコードを記述し直すというのは確かに重複した作業です。
リレーショナルデータベースを扱うシステムでは、少なくとも数十個から時には100個を超えるテーブルを扱います。これらすべてのテーブルに対してマッピングファイルやPOJOコードを記述しなければならないとしたら、JDBCベースのアプリケーションに比べたときの本質的な開発効率が上がっているかどうか疑問が残ります。また開発初期ではデータベーススキーマ定義が変更になることもしばしばでしょう。こうした変更時にPOJOコード・マッピングファイル、スキーマの同期を取る作業は、安易に無視してよい作業ではありません。
上述のような「重複した手間」を取り除くために、Hibernateの拡張ツールやサードパーティ製のツールによって、POJOやマッピングファイル、データベーススキーマのどれか1つからほかの2つを生成する方法が提供されています。これを「ラウンドトリップジェネレート」と呼んでいます。
環境/ソフトウェア | スペック/バージョン |
---|---|
hbm2java | マッピングファイルからPOJOコードを生成する |
hbm2ddl | マッピングファイルからデータベーススキーマを生成する |
middlegen | すでにあるデータベーススキーマから、マッピングファイルを生成する |
Xdoclet | Javaコードに記述されたXdocletマークアップを読み取ってマッピングファイルを生成する |
AndroMDA | UMLなどからPOJOコードを生成するModel Driven Architecture(MDA)ツール |
表2 ラウンドトリップジェネレートで使用するツール |
今回は、この中でも比較的使い勝手の良い「hbm2java」を紹介します。「hbm2java」は、Hibernateの拡張ツールとして提供されています。本連載第5回「リレーショナルデータにおけるメリットを体験」で使用したサンプルのPOJOコードをいったん削除して、Hibernateのマッピングファイルから再生成する実験を行ってみましょう。まずは、Hibernateのサイトからhibernate-extensions-2.0.2.zipをダウンロードします。解凍したら、「/tool」ディレクトリのhibernate-tools.jarと、「/tool/lib」ディレクトリのjdom.jarを本連載第5回で使用したサンプルプロジェクトの「build/lib」に置きます。
以下の例に従ってbuild.xmlファイルを記述してください。
<?xml version="1.0" encoding="SHIFT_JIS" ?> <project name="hibernate-codegen" default="codegen" basedir="." > <path id="class.path"> <fileset dir="build/lib" includes="*.jar" /> </path> <target name="codegen" > <taskdef name="hbm2java" classname="net.sf.hibernate.tool.hbm2java.Hbm2JavaTask" classpathref="class.path" /> <hbm2java config="config/hibernate.cfg.xml" output="src/" > <fileset dir="config/"> <include name="**/*.hbm.xml" /> </fileset> </hbm2java> </target> </project>
上記のbuild.xmlファイルを、同じくサンプルプロジェクトのルートディレクトリ直下に配置してください。次に、サンプルとして作成したsrc/sample/entityディレクトリのMember.javaおよびWorkGroup.javaファイルを削除してください。
Antを使ってcodegenタスクを実行すると、Member.javaファイルとWorkGroup.javaファイルが生成され、元どおりプログラムがコンパイル可能になります。
注意が必要なのは、マッピングファイル中で“int”や“string”などの省略形の型を指定した場合、生成されたコードではプリミティブ型のintプロパティが生成されることです。プリミティブ型はnullを扱えないので、この状態でnullデータが取得されたときには実行時にエラーとなってしまいます。これはマッピングファイルにラッパークラスを記述しておくことで、回避することができます。
Copyright © ITmedia, Inc. All Rights Reserved.