まえがき

以下、長い駄文が控えていますので、御託はいいからサンプルコードを見たい！という方はこちらを御覧ください。

ちなみに、リンク切れしていたり、情報が古くなっていたので、以前書いた Hibernate4を使ったJPA を、Hibernate5を使ったJPAとして、アップデートしました。

まえがき２（駄文の始まり）

Hibernate5を使ったJPAで、Hibernate 5を使って、JPA 2.1のAPI経由でRDBへのCRUDを行ったのですが、ORMを使っていていつも思うこと。

DBのスキーマとオブジェクトを対にする必要ってなくて、SQLの結果とオブジェクトが対になっていればよくないか？
SQLって、ロジックそのものに埋め込まれるべきではなくて、きちんと特定のオブジェクト（所謂 DataAccessObject)に隠蔽されるべきではないか？

後者はよく行われているが、前者は、JPAなどにも見られるように、そこまでやられていない。
むしろ、SQLそのものが隠蔽（というか自動生成）されていて、DBのテーブルと対となっている場合が多い（ORMがObject Relation Mappingだから当然と言われそうだが）

しかし、DBのスキーマを変えて、ORMでマッピングされるオブジェクトと、それを使うロジックそのものが影響を受ける（ロジックで使用しているカラムの追加削除なら、それに応じた処理が追加・変更・削除されるからいいとしても、SQLでしかいじらないようなカラムの場合はどうするの？という）

個人的な意見

これは、極めて個人的な意見ではあるのだが、SQLそのものと、その入出力をマッピングするロジックは、ある程度は開発者が意識すべきで、単純にSQLを発行するだとか、SQLのクエリへの変数のバインドなどは、ゴリゴリロジック書いたり、ツール使って吐き出すのではなく、動的に発行されればいいんでないの？
で、そもそも、ロジックが意識するのは、データベースのスキーマと対になったオブジェクトではなくて、SQLのクエリとのインタフェースじゃないのか？と

JDBIとは？

そんな想いを胸に秘めながら（笑）、DropwizardのGetting Startedを読んでいたら、JDBIなるものを発見し、試しに使ってみたところ、上述した不満を尽く解決してくれていて、同じことを考える方が居るものだと感銘を受けて、隠れファンとなりました:p

環境

今回は以下の環境にて開発しています。

JDK8
H2(インメモリDBとして使いやすいので、別途、DBMSをローカルに入れる手間がないので、サンプルコードを書くときに使っています。JDBI自体は、JDBCドライバがあれば、他のRDBMSでも動きます。MySQLとかでも動かしたことあるので)
JDBI
Gradle(ここ重要。あまり、他のサンプルコードでGradleを使っているものが見受けられなかったので)
TestNG(好みでしょう。アノテーション変えればJUnitでも動く程度のテストコードしか書いてません)
Eclipse + TestNGプラグイン（すみません。実は、Gradleのtestが動くかわかりません。Eclipseから動かしてます）

サンプルコード

冒頭に記述したものがそれです。
https://github.com/poad/examples/tree/master/jdbi-examples