ここ最近でO/Rマッピングもだいぶ一般的な言葉になってきたように思います。
良く目にするのがO/Rマッピングを使った場合と素のJDBCコーディングの場合
の比較ですが、それに加えてEJB CMPとの比較も加わっていることもあります。
『HibernateなどのO/Rマッピングツールを使うと、コーディング量は激減す
るがパフォーマンスは素のJDBCを使った方が良い』といったことが書かれて
いたりしますが、単なるコーディング量やデフォルト状態でのパフォーマンス
だけの比較をしてしまうのはちょっと危険な気がします。
コーディング量の比較で言うと、確かにJavaプログラミングのコーディング
という意味ではHibernateでのコード量は非常に少なくなりますが、各種設
定ファイル(hibernate.cfg.xmlなど)の存在を意識しておく必要があります。
EJBに関しては各種インターフェースに重複コードを書かないといけない点が
何かとヤリダマに上がってしまいがちですが、XDocletなどを使えば労力を
最小限に抑えられますし、EJB3.0ではそのあたりがかなり改善されます。
ちなみにHibernateでもXDocletを利用することができ、かなり重宝してます。
パフォーマンスにおいても注意が必要です。HibernateにしてもEJBにしても
関連オブジェクトについてはLazy Loadingを使うことは必須といえますし、
Hibernateにおけるキャッシュの利用やEJBにおけるセキュリティやトランザ
クションに関する諸設定にも注意が必要です。それらを誤ると、とんでもなく
非効率な処理になってしまう危険性もあります。
O/Rマッピングという観点だけで考えれば、HibernateとEJBを比較すること
には意味がありますが、EJBは単なるO/Rマッピングの枠を越えた分散オブジ
ェクト基盤としての性質があります。それだけに冗長な部分も多々あるわけ
ですが、開発しようとしているシステムがそうした仕掛けを必要としている
のかどうかの見極めをすることなく、単に実行されるSQL文やパフォーマンス
だけを比較対象としてしまうと、間違った方向に進みかねないような気がし
ます。
特にEJB CMPに関しては自動生成されるSQL文がかなり冗長になります。
関連オブジェクトで1:1の関連がある場合、新たに関連オブジェクトを
追加すると、元の関連オブジェクトと親オブジェクトの間の関連は自動的に
切り離されて、追加されたオブジェクトと親オブジェクトの間に関連が定義
されます。EJBではこうしたことを保証しているので、どうしても生成される
SQL文は冗長になりがちです。ですが、システム開発/運用上のメリットが
十分にあれば、そうした冗長さも受け入れることが適切な選択であるケース
もありえます。
結局のところ、HibernateにしてもEJBにしても各々の技術がカバーしている
範囲や開発の背景をしっかりと理解し、自分が携わっているシステムの要求
事項と照らし合わせて妥当な選択なのかどうかというトータルな視点で比較
検討を行う必要があるように思います。
