ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。 最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。

まじめなことを書くつもりでやっています。 適当なことは 「一角獣は夜に啼く」 に書いています。

「うらがみが Java まわりの ORM を知りたい会」 に参加してきた

Java の O/R マッパーまわりの話を知りたかったので、6/14 に行われた勉強会 「うらがみが Java まわりの ORM を知りたい会」 に参加してきました。 会場は和室でした。

Java まわりの O/R マッパー、あんまり詳しくないのでいろいろ知れて良かったです。 メモを残しておきます。

発表内容

Java の ORM、Doma の話 +α (@backpaper0 さん)

いろんな O/R マッパーについての簡単な紹介と、Doma の紹介。

  • 紹介された O/R マッパーのうち、使うとしたら JPA か Iciql か Doma かなーという気持ちになった。 (個人の感想です。)
    • ちなみに紹介されてる O/R マッパーのうち私がちゃんと知ってるのは JPA だけ。
  • Iciql と H2 Database を組み合わせて Android アプリで使うことができる (実際に製品開発に用いた) とのこと。
    • H2 Database は Android 用のビルド (?) があるらしい。
    • Java DB (Derby) を Android アプリで使おうとして挫折したことがあるので、今度は H2 Database を試してみたい。
Doma について
  • 公式サイト: Welcome to Doma — Doma 2.0 ドキュメント
  • 2 系は Java 8 以降。 1 系は Java 7 までらしい。
  • Doma、なんのライブラリにも依存してないらしい。
  • Pluggable Annotation Processing API を使ってる。
    • その仕組み上他の言語で使えない。
  • 原則としてクエリは SQL ファイルに書かないといけない。 (クエリビルダもあるが使わない方が良いらしい。)
    • SQL には if とか書ける。 ほぼ Java のコードを書けるっぽい。
  • コンパイル時にいろいろ検出。 (対応する SQL ファイルがなかったり中身が空だったり、アノテーションがなかったりすると)
  • DAO の引数や戻り値、エンティティのプロパティ (?) などにドメインクラスを使用できる。 (良い!!!)
  • 自動生成されるのはエンティティの補助クラスと DAO の実装クラスと、ドメインクラスの補助クラス。
議論
  • SQL で書くか Criteria API か?
    • Criteria API の方が IDE の補助があったりするけど、コードが膨らんだりするし、Doma だとコンパイル時に検証してくれたりするし SQL が良いと思ってる。
    • みたいな議論もあった。

F 社乙女チームの ORM (黒) 歴史 (@daiksy さん)

  • Scala でサーバーサイドを書くにあたっての O/R マッパー選択の歴史。
  • Play framework。
  • 今は Slick か ScalikeJDBC が良さそうだけど、昔は悩ましかった。
  • 最初: Squeryl
    • Implicit conversion を駆使するから IDE の補完が微妙だったりしてしっくりこなかったらしい。
  • 2 個目: ScalaQuery (のちの Slick)。
    • 使いやすいし、後々デファクトスタンダードになるのは理解できる。
    • Scala 2.9 → 2.10 のバージョンアップ時に Slick と名を変えて 2.9 系は切り捨てられた。
    • ScalaQuery を使っていた web アプリケーションはあえなくレガシー化...。
    • Scala はバイナリ互換性がないのがつらいよね。
  • 最後: MapperDao を採用。 (現在も。)
    • Squeryl, Slick, Activate, Circumflex-ORM, MapperDao, SORM, Scala ActiveRecord などを検討して、結果的に MapperDao。
    • DSL が結構良い。 普通の SQL っぽい感じで書ける。
    • ドキュメントの量とかは少ないので、今からなら Slick とか ScalikeJDBC のが良さそうな気がする。

Scala 周りの文化は全然知らないので、そんな感じなのかーと思いながら聞いてた。 Scala 便利だけど互換性とか大変そう。

JOOQ の紹介 (@chipstar_light さん)

  • 使ったことないけど紹介。
  • O/R マッパーというより DB アクセスライブラリ。
  • テーブルから Java コードを生成して、型安全な SQLJava 上で書ける、て感じ??
  • 既存の O/R マッパーでいい感じのがないけど JDBC をそのまま使うのも微妙、って感じの時に効果的に使えそう。

ORM 初心者が使おうとした (@KYON_MM さん)

3 つの O/R マッパー紹介
  • JOOQ
    • 機能的には使いやすい。 大体揃っているしユーザー数も多そう。
    • QueryDSL を駆逐してやるという勢いを感じる。
  • Iciql
    • とても薄いラッパー。 手軽で良さそう。
  • Slick
    • Play Framework のデフォルトになる予定。
    • 型型しすぎてる雰囲気。
      • Scalaz と同じ雰囲気。
    • ScalikeJDBC の方が好きな人が多いのでは?
議論的な話
  • ロックやリトライのサポートの話。
    • O/R マッパーでいい感じにサポートされているものは少ない。
    • ロックはともかくリトライは O/R マッパーがサポートすべきものではない気がするなーと思ったりした。
  • コネクションプールなどが O/R マッパーの内部で実装されていて不便なことが多い、とか。
    • テスト時にコネクションプールに手を入れられると便利。
    • BoneCP 使いたい、とか。
    • ScalikeJDBC では HikariCP が使えるようになった。 素晴らしい。

MyBatis (@s_kozake さん)

  • 大規模な案件に MyBatis で挑んだ。
  • MyBatis
    • 以前は iBatis という名前。
    • レガシーな環境、非正規化されたデータベース、SQL 文の実行を完全に制御したい場合によい選択肢となる。
    • 自動生成されるソースは?
  • MyBatis のラッパーをこざけさんが頑張って作っていい感じに使えるようになってた。 (すごい。)
  • Proxy クラス というのを初めて知った。
    • めっちゃ便利やん。

GORM めっさゆるい (@kazuhito_m さん)

  • リファレンス: 7 Object Relational Mapping (GORM) 2.4.0
  • Grails 用の O/R マッパー。
    • Grails とは独立させて使おうとすると大変っぽい?
  • GORM、Groovy らしさがあふれてるなーと思った。
  • ゆるい感じで使いたいならいいけど、まじめに大規模開発に使うと死にそう。