QueryRunnerの限界

SX-DbUtils

commons-dbutilsはORマッパーではありません。でも貧弱な機能ながら、BeanHandlerとかBeanListHandlerといったORマッパーみたいな機能が用意されてたりします。
でも逆は提供されていません。update(Object)とかそんなメソッド。ここがORマッパーではない、一つのラインではないかと思います。
dbutilsの拡張版を作るとき、DBに対してinsert/update/deleteといったメソッドを提供してしまうと、それはもはや簡易的なORマッパーだと思うのです。DBユーティリティとは言えなくなってきます。
たぶん、QueryRunnerで出来ること以上をやろうとしてしまったら、それはもはやcommons-dbutilsじゃあありません。すでにcommons-dbutilsを使っているプロジェクトには導入出来ないと思うし、習得のハードルが上がってしまいます。

じゃあ、INSERT/UPDATEは無理なのかというとそんなわけではなく、要はINSERT/UPDATEのSQLをさくっと作れればそれでいいんじゃないかと思うんです。SX-DbUtilsではBeanのインスタンスからSQLとパラメータ配列のセットを作り出す機能を提供するつもりです。そいつをQueryRunnerに渡せばINSERT/UPDATEも出来ます。

で、ここでPreparedStatementへのパラメータバインドが問題になってきます。
ORマッパーならばupdate(Object)などで渡されるオブジェクトから、テーブルのカラムとオブジェクトのプロパティのマッピング情報を取り出して最適な形式でバインドが可能です。しかしマッピングするオブジェクトもカラム情報もわからないQueryRunnerでは不可能です。

QueryRunnerの中で、PreparedStatementを取得する部分は1カ所に集約されているため、独自に拡張することでこの問題をある程度解決することもできますが、プロジェクトごとに独自QueryRunnerを作っているところではアウトです。コンポジションという手もありますが、やればやるほど複雑になっていき、こうしているうちにだんだんQueryRunnerじゃなくてもよくなってくる気がします。

結局、QueryRunnerには手を加えない方が望ましいと思うんです。
そうなると、ほとんどをデフォルトのQueryRunnerのfillStatement（PreparedStatementのsetObject）を呼び出すことになります。ここから先はJDBCドライバの優しさに依存してしまうわけです。でもたぶんあまり問題は出ないと思ってますし、問題あるときはいろいろ逃げ道があるとおもいます。

commons-dbutilsを便利にするのは割と簡単なんですが、便利にしすぎないってのが難しいんですよね。