バランス重視のDBアクセスI/F

DBFluteが提供する バランス重視 のDBアクセスI/F(インターフェース)について説明します。

• バランス重視
• 外だしsQLの重要性
• 全て外だしsQLで実装したら？
• ConditionBeanでバランスを得る
• とにかく二つの方法を覚えればよい
• 酸素と水、どっちが大事？

バランス重視

DBFluteは、タイプセーフな検索条件API ConditionBean と、自由度が高いながらsQLの安全性を保てる 外だしsQL(Outsidesql) を利用し、その適材適所のバランスを重視しています。

よくあるsQL

ConditionBean *タイプセーフ＆目的ドリブン

ちょいムズsQL

外だしsQL(Outsidesql) *2Way-sQL

e.g. MEMBER(会員)テーブルの検索(ConditionBean) @Java
MemberCB cb = new MemberCB();
cb.query().setMemberName_Equal("stojkovic");

e.g. MEMBER(会員)テーブルの検索(Outsidesql) @Outsidesql
select member.MEMBER_ID, ...
  from MEMBER member
 where member.MEMBER_ID = /*pmb.memberName*/'savicevic'

図 : バランス重視のDBアクセスの概念図

外だしsQLの重要性

複雑(非定型)なsQLは、アプリケーションで肝となるDBアクセスロジックである可能性が高いです。 その複雑性からバグも発生しやすく、時には実行計画と睨めっこしなければならないような大事な大事なsQLであり、それらは 2Way-sQL を大いに活用して最適なsQLを作り上げます。

全て外だしsQLで実装したら？

しかし、簡単(定型的)なsQLまで外だしsQLを実装するのはそれはそれで問題が発生します。

• DB変更に非常に弱い
• sQL特有のケアレスミスが多発
• sQLの命名やフォーマット等の規約の不統一による可読性の劣化
• 大量のsQLファイルの管理コスト

実装数の割合は、複雑(非定型)なsQLに比べて簡単(定型的)なsQLの方が圧倒的に多く、上記のような問題が発生します。これらは 2Way-sQL のおかげで大分解消はされますが、完全ではありません。

ConditionBeanでバランスを得る

そこでDBFluteは、簡単(定型的)なsQLに関しては完全タイプセーフな "ConditionBean" で安全かつ速い実装を提供し、 その分、現場のディベロッパーには複雑(非定型)なsQLに集中してもらいたいという考えを持っています。

理想的にはどちらか片方の方法で全てのsQLを実現できるのが良いに決まっています。 しかし、それはシビアな開発期間、シビアなパフォーマンス要件など様々な要因を考えると不可能であり、 バランスを重視したDBアクセスI/Fが(少なくとも今の時代の)現場に一番フィットすると判断しました。

およそ、8 割を ConditionBean で、2 割を 外だしsQL(Outsidesql) で！

とにかく二つの方法を覚えればよい

もちろん、いくらバランスと言ってもやり方が三つも四つも存在すると、わかりやすさが半減しディベロッパーの学習コストが高くなって効率が良くありません。 また、都度都度プロジェクトでどの方法をどう使っていくかの実装ポリシー策定も必要になってしまいます。 これは他のO/Rマッパでありがちな問題でした。ディベロッパーがどれをどうやって実装すれば良いのか迷うのです。 DBFluteでは、とにかく二つだけ ConditionBean と 外だしsQL(Outsidesql) を覚えてDBアクセスします。どのプロジェクトであろうとポリシーは同じです。

また、ConditionBean は完全タイプセーフであるがゆえに(*1)逆に実現できることが限られ、外だしsQLとの棲み分けはハッキリしています。 ConditionBeanのスコープ といったようなドキュメントも用意され、ディベロッパーは一定の判断の流れで実装していくことができます。

*1: 部分的なsQLをアプリケーションプログラム上で文字列として設定することはできないため、プログラム上での "自由で危険な埋め込みsQL" が抑制されています。