昨年に続き「DBFluteフェス2014」に行ってきました。
以前、渋谷Java*1でDomaの@nakamura_toさんが参加されていた際に@jfluteさんがDBFluteフェスへの参加を呼び掛けるというプロレスのような展開があり、往年のSeasarファン垂涎のDBFluteフェスが実現しました。
なんとなくtweetの方に力を入れていたこともあり、メモを取っていませんので感想メインです。 (各コマで2セッションだったため、参加したセッションについてのみとなります)
(イベントページ)
(DBFluteコミッタのjfluteさんの記事)
いきなり極限ConditionBean by @jflute
いきなりぶっちゃけると、DBFluteは使ったことはないです。 名前は昔から知っていましたが、Seasarの名前を冠していなかったこともあってほぼノーマークでした。
初めてその中身を知ったのはClubDB2のDBFluteの回(http://db2.jugem.cc/?eid=2580)で、 「ここまでやれるんだったら『SQLを書かない』O/Rマッパーはアリだな」と思わせる内容と Eclipseのショートカットキーと補完を駆使した高速ライブコーディングに衝撃を受けました。
相変わらず淀み無いライブデモンストレーションでしたが、今回はJava8のラムダに対応してさらに高速化。 (と、言い切りたいところですがEclipseのラムダの補完の効きがまだイマイチで、「(文末の)セミコロンを付けてやると補完が効くよ!」というワークアラウンドの解説がありました。)
余談ですが、今は立場的にアプリ開発で使うフレームワーク等の決定に強く影響を及ぼせる立場にあり、さらに新規モノの開発が山ほどある状況なので、DBFluteを使いたいという思いもあるのですが、関係者の学習コスト(というか時間)の問題が今のところどうにもならなそう、という状況だったりします。 逆に、きちんとDBFluteの内容と手技(と思想)をきちんとマスターしているのならば、この上ない武器になるのではないかと思います。
個人的にはDBFluteの書籍があると、採用ハードルがちょっとは下がるんじゃないかな、と思いました。
DomaのSQLテンプレートのしくみ by @nakamura_to
DBFlute・Domaともに大きな影響を受けているのがS2DAOの2Way-SQLで、これには私自身も大きな衝撃を受けました。このS2DAOの特性を色濃く受け継いでいるのがDomaです。(と勝手に認定)
今回のセッションは、DomaのバックグランドやSQLテンプレート(2WaySQL)の説明と共に、SQLテンプレート処理の仕組み(構文処理)についての説明がありました。 よく考えると当然なのかもしれませんが、単なる置換ではなくSQLをSQLとして解析して処理しているんですね。
Domaのテンプレートエンジンは、S2DAOのものは使わずにスクラッチで開発されており、 Domaでは構文木を採用することで処理の差し込みなどをやりやすくしているようです。(ぜひDomaをハックして機能拡張して欲しい!とのこと)
DBFluteの外だしSQLが意外におもしろい by @jflute
DomaのSQLテンプレートの次はDBFluteのテンプレートのお話。
コメント内のタイトルや概要(説明)記載の強制、自動生成ドキュメントへの反映など、「本来こうあって欲しいんだけどなかなかやってくれない。だからこうすればやってくれるだろう」という工夫を常に加えているとのことです。
あと、作成したSQLからEntityを生成してくれるんですね。 DBから生成するのは結構見かけるんですが、SQLからも生成するのって珍しい気がします。 「select結果の型は実際にSQLを叩いてみないとイマイチはっきりしない」というのはなるほど、とい思いました。
Doma、DBFluteコミッタ対談!
今回はこれを見に来た、という感じです。 あらかじめ質問募集とかしてくれたらよかったかなぁ、とか思いました。
OSS開発は時間の確保が肝要なんですね。 社会人になってからプライベートでがっつり時間をかけて何かを作る、というのがあまりなくなってしまったんですが、やはり本人次第ですね。
あと、薄々は感じていましたが、同じS2DAOを出発点とした2つのプロダクトの基本的な思想がかなり違うのだということを改めて実感しました。
逆に、共通点を見出すとすれば「JPAやJavaEEとは距離を置いている」というところでしょうか。私見ですが、やはり(母体である)SeasarがJ2EEの対抗であったことも影響しているのかと思います。
jflute締めトーク
Java8の文法面での変更としては、ラムダと共にOptionalがインパクトの大きいものとなっており、DBFluteやDomaでもJava8対応版ではともにOptionalをサポートしています。個人的には関数型言語には疎くてOptionalのいいところがよくわかってなかったですが、マッピング系との相性はよさそうですね。
話にもありましたが、ER図を書いてるプロジェクトってどのくらいの割合なんでしょうね。 個人的には最近は要件定義書とER図と画面モックを並行で作って基本設計にバトンタッチする、という業務ばかりなのと、ER図からDDLを生成するのが普通になったので、ER図は普通に書きますね。
あと、昔CGMサービス運用をいくつも抱えていたので「FKはパフォーマンス面で悪」という思いがありましたが、jfluteさんの話や今はメインが業務系という状況であることから「FK貼らなきゃだめでしょ」という考えにシフトしてきています。 まぁ、ERMaster使ってるとFK貼らないとリレーション書けないし(笑)。
という感じの濃厚な半日でございました。 関係者の皆様、ありがとうございました&お疲れ様でした。