システム開発で思うところ

Java EEを主にシステム開発をしながら思うところをツラツラを綴る

JJUG ナイトセミナー 「Java O/Rマッパー特集」に参加してきました #jjug

まとめ

【東京】JJUG ナイトセミナー 「Java O/Rマッパー特集」 7/26(水)開催 #jjug - Togetterまとめ

スライド

speakerdeck.com

Doma

www.slideshare.net

www.slideshare.net

スライド(関連)

speakerdeck.com

www.slideshare.net

感想

私が使用しているのはJPAで、話を聞いたうえでJPAで良いかな、と思った。

理由

JPQLとかORMらしさに拘っていない

基底となる技術要素がRDBである以上、実行SQLから目を背けることは出来ないということから、私は割と気軽にNativeQueryを使っている。標準SQLに限ればDB製品依存も言うほど気にしなくて良いと思っている*1
ただコード内で直接文字列操作をするのは好きではないというのと、SQLの確認のやり易さということでSQLファイルを読み込む共通部品は作った。今は、フラットに格納しているけれどDomaのようにパッケージに準じたフォルダで格納するというのは良さそうだから、今後、改修しよう。

テーブルにEntityクラスが1対1にも拘らない

@ReadOnlyをつけたEntityDTOとして参照のためだけに作ってDomaみたいにフラットな結果を後からゴニョゴニョしている。

キャッシュをあてにしない

キャッシュというかEntityManagerが原因で困ることが割とあるので、あてにしない仕組みにしておいた方が無難と思う。例えばflushはちゃんとコールするとか、selectはDBから最新のものを取ってくるようにするとか、そういうこと。

標準だから

JavaEE標準の看板は選定理由として大きい。思考停止していると言われたら その通りだと思う。ORMに対してトランザクションとクラスマッピングの基本的な仕組みしか求めていない私には何かしらルールと実装があれば良いので「標準」は訴求力になる。

あえて「好み」をいうと…

S2JDBCは良かった。2 way SQLが便利だった印象があるので。なので 今回、話を聞いてDomaが良さそうと思った*2
ただJPAを止めてまで、aptベースの仕組みを導入するか?というと難しいかなぁ。apt自体は理解をすると決して尻込みをするような技術ではないし、実際に動くコードが見られるので むしろ安心感すらあるんだけれど、分かってもらうためのハードルが高いかも。apt自体がもっと使いやすくなれば良いんですけどね。
ということもあって、今のところDomaを使うよりもJPAを便利に使えるための仕組みの精錬を優先しようかと思った結果『JPAで良いかな』という結論に至った次第。

*1:実際に移植しているわけではないので困った経験はないけれど

*2:以前、aptの教材・参考としてDomaのコードをみたけれど、ORMとしては既にJPAを使っていた&一通り仕組み作りまでしてしまっていたのでスルーしていたので、今回、話を聞けて良かった。