• 概要

• 流れるようなインターフェースと脱CoC

• 90%のSQLを自動生成する

• Javaの良さを生かす

• SQLの扱いが簡単

• シンプルなプロパティ

• 学習コストが低い

• トラブリにくい

• より良いJPA

S2JDBCは、データベースプログラミングの生産性を10倍以上高めることを目標として作成した Seasar2のO/R Mapperです。何に比べて生産性が10倍かというとJava標準のJPA(Java Persistence API)に対してです。次のような特徴があります。

「流れるようなインターフェース」とは、文章を記述していくようにメソッドを呼び出していく手法です。 詳しくは、ファウラーたんの 流れるようなインターフェース を参照してください。あれこれ説明するよりも、検索の例を見たほうがわかりやすいでしょう。

一番の特徴は、可読性の高さです。何をやっているのかが一目瞭然ではないでしょうか。

二番目の特徴は、IDEと組み合わせることで、APIを覚えていなくても自然に使えることです。 何か記述したかったら、コード補完によって使える単語(メソッド)が自動的に選択されます。 これが脱Convention over Configuration(以後CoCと省略)につながってきます。

CoCは、「規約を守っておけばフレームワークが自動的に設定してあげる」というもので、CoCによって開発者は、あまりソースコードを書かなくてもすむようになります。 CoCは、確かに私たちを設定ファイル地獄から救ってくれました。

しかし、CoCにも暗黒面があります。ソースコードに明示されている部分が少ないので、 自動化されている部分がブラックボックスになり、 規約を知らない人が見ると何をやっているのかがまったくわからなくなってしまうのです。

また、規約を知らないと何もできなくなるので、ちょっとしたことでも、自分の知らないことであれば、 いろいろ調べたり試行錯誤を繰り返すことになります。このような試行錯誤の時間は馬鹿になりません。 最終的なソースコードは確かに少なくなったけど、 かかった時間は大して変わらなかったなんてことも十分にありえます。 自動化されているので最初はとっつきやすいのですが、知らないことやイレギュラーなことに弱いのです。

それに対して「流れるようなインターフェース」の場合は、 可読性が高いので、誰が見ても何をやっているのかが明快です。 また、IDEがコード補完によって自動的にできることを教えてくれるので、事前に知らなくても使いながら学習していくことができます。 知らない機能を使うために試行錯誤を繰り返す必要はありません。 単語(メソッド)の間違いもそんなメソッドないよとIDE(コンパイラ)が教えてくれます。

「流れるようなインターフェース」によって、CoCより安全で効率的な開発が可能になるのです。

SQLは文字列で組み立てるため、書きづらく間違いやすいものです。 S2JDBCは、「流れるようなインターフェース」により、SQLを自動生成します。 先ほどの例をもう一度見てみましょう。

これは、次のようなSQLに展開されます。

クエリの呼び出しがSQLに対応しているので可読性が高いだけでなく、 selectリスト句でのカラムの指定や結合の指定など面倒な指定を する必要がありません。

これに対し、Javaの標準であるJPA(Java Persistence API)はどうでしょうか。 JPAもSQLを自動生成できます。それでは、同じことをJPAでやってみましょう。

最近、 JavaからRubyへ なんて言われ、生産性の低い言語としてすっかりレッテルが貼られてしまったJavaですが、 古いJavaのイメージで語られていることが多い気がします。

アノテーション、Generics、列挙型、可変長引数、Auto Boxingなど、 今のJavaには、生産性を向上させるための機能がいろいろ用意されています。 ただ、残念なことにこれらのすばらしい機能をフルに活用したフレームワークは あまりないのが現状です。

S2JDBCでは、Javaのよさを生かし、生産性を向上させます。 例えば、先ほどのJPAの戻り値のキャストを見てみましょう。

SQLの自動生成ですべてがうまくいけば問題ありませんが、 実案件では、複雑なSQLを自前で組み立てる必要が出てくる場合があります。 複雑なSQLで複雑な結果を返す場合、JPAでは次のようになります。

Javaでプロパティを作るには、フィールドとgetter、setterメソッドの定義が必要でした。 getter、setterメソッドは、カプセル化の観点から必要とされてきましたが、本当にどんな場合でも必要なのでしょうか。

Javaでは、テーブルの一行に対応するデータの入れ物をエンティティと呼ぶことが一般的です。 テーブルのカラムのデータは、もともとpublicな存在なので、エンティティのプロパティがカラムに一対一に対応するなら、 プロパティのgetter, setterメソッドを省略して、 publicフィールドにしても良いのではないでしょうか。

エンティティはテーブルの鏡であるという位置づけにするなら、エンティティのプロパティをpublicフィールドにするのも別におかしなことではありません。 S2JDBCでは、エンティティはテーブルの鏡であるという立場をとることによって、エンティティのプロパティをpublicフィールドとして定義できるようにしています。 もちろん、publicフィールドに抵抗のある方は、これまでどおりに、getter, setterメソッドを定義することもできます。それでは、getter, setterメソッドのありなしを比べて見ましょう。

どっちがすっきりして見やすいかは一目瞭然ですね。 これは、すべてのプロパティをpublicフィールドにすべきだという意味ではありません。 カプセル化が必要なケースももちろんあります。 でも、エンティティがテーブルの鏡だとする全体が成り立つなら、 プロパティをpublicフィールドにするのも十分にありだということです。

プロパティへのアクセスも

よりも

のほうが直感的で、気分よく記述できるでしょう。このような気分のよさも生産性につながってくるのです。

昔のフレームワークなら、機能が盛りだくさんで、使いこなすには時間がかかるけど、 使いこなせれば、威力を発揮するというのも許されたでしょう。 Hibernate は、まさしくそのようなフレームワークです。

しかし、時代は変わりました。今は、一ヶ月以内に成果を出すことを求められるのもよくある話です。 使いこなすのに時間がかかっては間に合わないのです。

そのような時代の要求を受け、機能を盛りだくさんにするのではなく、 データアクセス用のフレームワークとして本質的な機能に集中することで、短期間で使えるようになることを可能にしました。

このドキュメントに対応するのがHibernateの Hibernate Annotationsのドキュメント と Hibernate EntityManagerのドキュメント になります。学習コストが低いということが実感していただけるのではないでしょうか。

学習コストが低い でも取り上げましたが、機能が盛りだくさんだと、覚えるのに時間がかかるだけではなく、 トラブルに見舞われやすくなり、その解決に時間がかかるようになります。

例えば、一対一、一対多、多対一などのエンティティ間の関連を取り上げてみます。 それぞれの関連は、データをロードするタイミングを指定することができ、関連のプロパティにアクセスしたときにはじめてデータをロードする Lazy loading と、関連元のエンティティにアクセスするのと同時に関連先のデータをロードする Eager loading があります。

従業員と部署のエンティティに多対一の関連がある場合、 Eager loading だと、従業員を取得するのと同時に部署も取得されます。 Lazy loading だと、従業員を取得したときは、 単に従業員のデータだけが取得され、部署のプロパティにアクセスしたときにはじめて 部署のデータが取得されます。

また、それとは別に、関連は Lazy loading にしておいて、クエリを実行するときに、どの関連を結合で取得してくるかを指定する方法もあります。 この方法は、フェッチ結合と呼ばれます。以前のサンプルでも次のようにフェッチ結合が使われていました。

どのようなケースにも対応できるようにするため、このようにいろいろな選択肢が用意されているのですが、 いろんな選択肢があるのでトラブルが起こる確率も増えてしまうのです。

例えば、一対一、多対一には Eager loading 、一対多には Lazy loading を適用するというルールにしたとしましょう。JPAのデフォルトはそうなっています。

Eager loading が設定されている関連元のエンティティにアクセスするときは、必要かどうかにかかわらず常に関連先のデータまで取得されてしまうため、 大量のデータを取得する場合は、パフォーマンスやメモリ不足の問題を引き起こすことがあります。 少量のデータでテストしていたときには気づかず、本番相当のデータを用意したときにはじめて 発覚するというのも困りものです。

それでは、 Eager loading を Lazy loading に変えれば、すべての問題は解決するのでしょうか。残念ながら次の「N+1検索問題」を引き起こします。

1000件の従業員のリストを表示するという機能があるとしましょう。 従業員のデータ以外に部署名も表示させる必要があるとします。 最初の1回の検索で1000件の従業員のデータを取得します。 その後、部署名を表示させるために、従業員.部署.名前のようにアクセスすると、 部署のプロパティにアクセスした瞬間に Lazy loading がおきます。これが従業員の件数分(N)起こるので、「N+1検索問題」といわれています。

大量の検索が発行されるので、深刻なパフォーマンス問題を引き起こします。 実際は、同じ部署へのアクセスはキャッシュが使われるので、N件起こることはないのですが、それでも部署の件数分の検索が行なわれパフォーマンス問題を引き起こすことには変わりはありません。

最も良い解決策は、関連は Lazy loading にしておき、検索のときにフェッチ結合を使うことです。 Lazy loading にするのは、 Lazy loading にしたいからではなく、 Eager loading させないための回避策です。フェッチ結合は、特定の検索のときだけ、 Eager loading になるような効果があります。

ここまで説明してきたようにJPAは、機能が豊富だけどトラブリやすいという問題があります。 S2JDBCでは、トラブリにくくするために、いたずらに機能を増やすのではなく、トラブリやすい機能は意図的に削っています。

例えば、関連のLoding問題についていえば、 Eager loading も Lazy loading もサポートせず、次のようなフェッチ結合のみをサポートしています。 join()メソッドのデフォルトはフェッチ結合になります。

実際の開発において、予想外に多くの時間を費やしているのはトラブルシューティングの時間でないでしょうか。 トラブリにくくすることも、生産性向上の重要な要因なのです。

これまで、JPAの問題点をいくつか指摘してきましたが、 JPAは標準であり、一方的に無視してよいものでもありません。 そこで、S2JDBCでは、エンティティとテーブルのマッピングの仕様は、JPAとあわせ、いまいちなEntityManagerやJPQLの部分は、独自仕様でいくことにしました。

JPAを使ってパフォーマンスが出なかったり、 トラブルに巻き込まれて困っている方は、より良いJPAとしてS2JDBCを使ってみてはいかがでしょうか。