S2JDBCで複雑なSQLもタイプセーフに流れるようなインターフェースで書いた方が良いと思う理由

昨日書いたS2JDBCを使った複雑な↓のクエリ。

public ThesisProfUser findByUidAndYear(String userId, int year) {
    return select()
        .leftOuterJoin(year())
        .leftOuterJoin(profUser())
        .leftOuterJoin(thesisAssignmentList())
        .leftOuterJoin(thesisAssignmentList().thesisStudentUser())
        .leftOuterJoin(
            thesisAssignmentList().thesisStudentUser().studentUser())
        .leftOuterJoin(thesisAssignmentList().assignmentVoteList())
        .where(
            new ThesisProfUserCondition().profUser().uid.eq(userId).and(
                new ThesisProfUserCondition().year().year.eq(year)))
        .getSingleResult();
}

これだけ見たらSQL生で書いたり、外だしSQLファイルで書いた方が良いと思う方もいると思います。てなわけで、複雑なSQLも↑のようにタイプセーフに流れるようなインターフェースで書いた方が良いと思う理由を書いときます。とても簡単な理由です。

• DBスキーマを変更してEntityやNamesをS2JDBC-Genで生成し直すと、DBスキーマの変更に応じてコード中のどこを変更すべきかをコンパイラ(Eclipseなど)が「エラーとして教えてくる」

これです。属性名が1つ変わっただけでもコード中から参照している箇所を全部自力で探し出すのはツライですよね。1からコードを書く時に流れるように次々とEclipseが補完してくれるという大きなメリットもありますが、もっと重要だと思うのが↑です。

このことに関しては、S2JDBC-Gen開発者のtaediumさんがプッシュされているS2JDBC-Genのコンセプト機能?であるEntityからDBスキーマを生成する機能ではさらに一歩先をいっていると思います。スキーマから生成して後からエラー箇所を直すより、先にEclipseのRefactorでEntityを修正させてしまえば、1発でコード中のほとんどの箇所を直せてしまいます(JSPやMayaaなどのビュー部分で参照している箇所も一緒にRefactorされればさらに良い。。)。ただ、単純な修正ならこっちの方が確実で早いですが、テーブル構造的に大きく変えるとなると、リレーション部分をグラフィカルなERダイアグラムで直した方が全体が見通せて考えやすいかなとも思います(てなわけで、EntityをグラフィカルなERダイアグラムとして表示して編集できるPluginがあれば、EntityからDBスキーマを生成する機能が爆発的に使われるかも？)。

ちょっと脱線しましたが以上のような理由で、手元にあるコードではすべてのクエリをS2JDBCを使ったタイプセーフに流れるようなインターフェースで書いています。もしSQLファイルを使う例外があるとしたら、ぱっと思いつく中では次の2ケースぐらいでしょうか。

• DBに定義してある特殊なストアドプロシージャを使いたい
• DBが持つ独自関数を使いたい

でも、S2JDBCでいくらDBを簡単に扱えるようになってもまだまだ開発上で解決しない問題があります。それは、S2JDBC関係なく、根本的にDBスキーマの設計がダメダメなら欲しいデータをDBから取得するのはコストが掛かるし、コンパイラがエラー箇所を教えてくれるとはいえ構造的に大きく変更になればロジック部分も考え直さないといけなく、変更コストはやっぱし甚大。

というわけで、今使っているDBスキーマも修行が足りないとひしひし感じているので、もっと知識を集めて良くしたい。