今からでも遅くない　JPAを学ぼう！（前編）
O/Rマッピングフレームワークへの招待

JPAとは

　JPA（Java Persistence API）とはオブジェクトの世界からリレーショナルの世界へ、あるいはその逆への変換を行うためのAPIです。

　それでは何もJPAを使わずともHibernateやiBatisを既に使っているから必要ないのではと考えられた方も多いかと思います。確かに既にそれらのO/Rマッピングフレームワーク（以降、O/Rマッパー）を利用されているのであれば特に必要ないのかもしれません。

　そう思った方も少し待ってください。データベース製品の多様性を隠ぺいするためにJDBCが考えられたように、あるいはMOM製品の多様性を隠ぺいするためにJMSというAPIが考えられました。ところがO/Rマッパーの違いを隠ぺいするためのAPIは存在しなかったのです。iBatisを使用されている方にはあまり嬉しくないかもしれませんが、JPAの仕様作成の中心人物こそHibernateプロジェクトの創始者であるGavin King氏であり、Hibernateの血を色濃く受け継いでいます。

JDBCを使ってもO/Rマッピング

　直接JDBCを使っても、それも立派なO/Rマッピングです。筆者はこの方法が駄目だと主張するつもりは毛頭ありません。テーブル間の関連が非常に複雑である場合、JDBCのAPIを使って記述した方が楽な場合もあります。筆者が参画していたプロジェクトでもコストをかけないという制約のもとBI（Business Intelligence）に似たシステムを構築したことがありますが、このような場合、SQLを自由に駆使できるJDBCを使った方がO/Rマッパーを使うよりもむしろ楽だと感じました。

O/Rマッパーが必要な理由

　この理由は、既に言いつくされた感があるため言及する必要がないと感じています。それはオブジェクトモデルとリレーショナルモデル間のマッピングが難しいことにあります。インピーダンス・ミスマッチという言葉がよくつかわれますが、これを解消するための試みがHibernateなどのO/Rマッパーです。やはりプログラムの中にSQL文が混じりこまず、可読性が高まるということもあり、保守性も優れているという理由から支持されているのだと思います。プログラムをよりオブジェクト指向化するためのフレームワークを提供してくれるO/Rマッパーは非常に有難い存在と言えます。

よくある誤解

　O/RマッパーさえあればRDBの知識は必要ないと思っている方が多いようですが、コーディングの際にはRDBを意識する必要があります。意識しつつもSQLを直接書く必要がないだけの話です。ある程度RDBやSQLを知っていることがO/Rマッパーを使用するための前提であるとも言えます。常に過度な期待は禁物です。