2019年1月31日（木）、JSUG勉強会2019その1「Spring Data JDBC正式リリース記念！データアクセス特集」に行ってきたので、Spring Data JDBCについて現時点での理解をまとめました。

Java ORマッパー選定のポイント

発表スライドはこちら。
以下、発表内容について印象に残った点です。

会場アンケート

• MyBatisを業務で使っている人：7割くらい？
• JPAを業務で使っている人：1割くらい？
• Bootiful SQL Templateを知っている人：1割弱？

安易にJPAを採用することについての警告

JPAの採用について、かなり警告されていたのが印象的でした。
（「とりあえずJPAにしようと思ってるんですけど…」という受講者に接する機会が多いのかな、と推察）
多田さんは過去の登壇資料で「Spring Data JPAは使える」と書かれていましたが、これはあくまで “possible” という意味だったんだな…と実感しました。
個人的には、プロトタイピングではJPAを使うとほとんどSQLを書かなくてよいので助かりますが、プロダクトへ採用する勇気と知識はまだありません。

クエリビルダー型のプロジェクトの多さ

クエリビルダー型に分類されるものが多く、9種類ほど列挙されていました。
これは、これまで人類がインピーダンスミスマッチと戦ってきた歴史¹だなぁ…と感じました。
結局、ORMに銀の弾丸は存在しないので、プロジェクト毎にうまく選ぶしかないと思います。
そういう意味では、選択肢が多いのは良いことですね。

Bootiful SQL Template

過去の谷本さんの発表Spring Bootを始める時にやるべき10のことにあるBootiful SQL Templateですが、会場での知名度は思った以上に低かったです。
ちなみにAcroquest Technology社ではプロダクションで採用されているとのこと。

早わかりSpring Data JDBC

発表スライドはこちら。
以下、発表内容について印象に残った点です。

会場アンケート

JPAが好きな人：1人（会場は50人弱）

JPA…

Spring Data JDBCの位置づけ

以下のようなライブラリだそうです。

• RDBアクセス用のSpring Dataファミリー
• JPAを使わずにJPAのようなRepositoryを実装できる
• キャッシュや遅延読み込みなどをサポートしない

ターゲット層としては「RDB使うけどJPAは使いたくない、だけどSpring Dataインタフェースのメリットは享受したい」という方でしょうか。
Spring Data JPAのハマりどころを減らしつつも、便利なところは取り込もうとしているように見えます。

海外でのJPAの使用比率は高い

海外ではJPAを採用している比率が高いようで、こちらの投票では57%がJPAとのことでした。
これは正直かなり意外でしたが、IT業界を取り巻く環境が大きく違うのかもしれません。
海外はITスキルが高く習熟している人が多いのか、それとも日本では古いDBを引きずって運用されがちなのか…ともかく世界的にはJPAがデファクトスタンダードなようです。

現時点でサポートされていないJPAの機能

JPAでサポートされている以下の機能について、Spring Data JDBC 1.0.4時点では非サポートとのことでした。

• PagingAndSortingRepository
• メソッド名からクエリの自動生成
• 複合主キー
• Embeddable

PagingAndSortingRepositoryやクエリの自動生成は便利だったので、今後の発展に期待してます。

集約として保持するインスタンスが一旦全て削除される

注意点として、「部門を削除したら社員全員が削除される」ということが起こります。
これはパフォーマンスや設計の安全性などを考えると、ちょっと大きい制約のように感じられました。

ただSpring Data JDBC 1.0.4のReferenceでは以下の記載があり、現バージョンにおける制限事項のようにも見受けられますので、今後改良される可能性もありそうです。

In the current implementation, entities referenced from an aggregate root are deleted and recreated by Spring Data JDBC.

その他

以下のような機能も提供されているようです。

• Repositoryの操作に対してイベントトリガーを設定
• 監査用カラムの設定

全体の所感

個人的に「MyBatisを使用していた場面において、Spring Data JDBCは新たな選択肢となり得る存在」と捉えました。
これまでRDBアクセスでSpring Dataのインタフェース（CrudRepositoryなど）を使うにはJPAしかありませんでしたが、JPAはキャッシュや遅延読み込み等の機能でハマることも多いため、採用する際のリスクにあまり見合わないと感じていました。
しかしSpring Data JDBCではハマり所になりやすい機能が削られているため学習コストも低く、プロダクトへの採用リスクも低くなっているように感じられます。

一方で、MyBatisに比べるとテーブル設計やマッピングなどの柔軟性が失われる印象を受けました。
現在MyBatisが採用される理由の一つはその柔軟性にあると思っているので、置き換えるにはかなりの注意を要すると感じました。

JSUG勉強会は今回が初参加でしたが、キャンセル待ちが多かったこと、そしてブログでの発信もコミュニティへのコントリビューションの一つだと思って、書いてみることにしました。
今後も継続的に勉強会へ参加していきたいと思います。

JSUG勉強会の開催関係者の方々、ありがとうございました！

---

1. 数年前にDocument DBが持て囃された一因だと思っています。今ではRDBにJSONを突っ込む、なんてこともできますが… ↩︎