S2Dao...Uuji...DBFlute... 



ひがさんがBLOGでUujiを紹介していますね。

やはりDoltengと連携してとても良さそうな仕様に

なっている感じです。

Uujiは「アプリケーションで使う90%以上のSQL文は自動生成」

と謳われています。

DBFluteと見事かぶる感じです（＾＾

SeasarといえばS2Daoだっただけに、こういう思想はS2の世界じゃ

流行らないのかなと思ってて、でもDBFluteでそれを打ち出して

みたのですが、どうやらS2の中で競合が生まれた感じです。
もちろん同じ思想の中にも違いはあるとは思います。

と、色々比較しようかと思いましたが、まだできてないもの

を色々論じてもしょうがないので、DBFluteの思想だけおさらい

しようかともいます。
A. 開発者が覚えるのは２つ。

   ・定型的なSQLは、“ConditionBean” ※DBFluteの機能

   ・特徴的なSQLは、“外だしSQL”     ※S2Daoの機能

   →実質、「アプリケーションで使う90%以上のSQL文は自動生成」となる。

     (Uujiと同じですね...)
B. ConditionBean主義。

   ・Table名もColumn名も全てTypeSafe。

   ・Eclipseの補完機能でMethod選ぶだけのさくさく実装。

   ・可読性重視。(Torque/Hibernateの二の舞は踏まない!)

   ・PagingもOK(S2Pager不要)。
C. DB変更よ来い！ (...でも来ないならこないでOK)

   ・一括自動生成

   ・Entity/Dao/ConditionBean全てにおいてGenerationGap

   ・ConditionBeanの徹底したTypeSafeでDB変更の影響をCompileでCatch。

   →10%の外だしSQLだけをしっかりUnitTestで自動化しておけば影響を網羅。



「A」に関して：
外だしSQLの出番が10%であれば、ほとんどの開発者はConditionBeanでその

プロジェクトでの生涯を閉じることになります。

アーキテクトは色々理解していなければなりませんが(build.propertiesとか)、

一般開発者においては、おおよそ直感で実装できることを心がけています。

ConditionBeanは、Eclipseの補完機能さえできれば

おおよそ「直感とちょっとのドキュメント」でいきなりDBアクセス可能

を目指しています。（実際に利用者からそのような感想を頂きました）
現場では、３日間の学習コストも節約したい状況が生まれています。

それはそれで別の大問題ですが、現実なんとかして解決しないといけません。

開発者はWEB周りのFramework/新しいProjectの規約/派遣先での新しい環境など

覚えること一杯です。せめてDB周りは楽させてあげたいのです。
勘で実装できるってのは大事です。各人の勘に頼るのは個人差が激しくて、

Management的には計算に入れてはいけませんが、Agileな開発においては

威力を発揮します。3日間教育期間を設けてそれを使い切らければ

どんなにManagerは喜ぶことか...



「B」に関して：
(「A」で語りすぎたのであまり話すことがない!?)

TorqueのCriteriaで嫌だったのが、Java上でQuery組んでるのにさくさく感がない。

演算子の指定Column名の指定をどっかで定義された定数から取得するところ、

意外にこれ面倒で嫌なんです。

ConditionBeanは、{.}を押して選んで指定完了。

(その代わりConditionQueryのClassの膨張がTradeOffになりますが...)
さらに色々ありますが、Policyについては↓↓↓

http://dbflute.sandbox.seasar.org/ja/condition_bean_policy.html



「C」に関して：
DB変更って...絶対あります。

それはそれで別の大問題ですが、現実なんとかして解決しないといけません。

中以下Skillの開発者を大量に投入するような開発で、DB変更がCompileErrorに

ならない実装だと、えらい大変です(でした)。

DBFluteは、EntityもConditionBeanもQueryも全てTypeSafeと型苦しいですが、

それはDB変更を備えてのことです。(無論Spell-Miss防止もありますが)
また、自分はDB変更って必要悪だと考えております。

自分はDB設計を主に生業としています(まだまだ未熟ですが)。

Programは実装を綺麗にするためにRefactoringが可能です(結合Test前まで!?)。

DBはRefactoringがとてもしづらい状況にあります。

SQLをもう書かれてしまってるので、必須でないDB変更は暴動になります。

逆にそれが足枷になり、「理想でないDB構造」を提供しなければならない状況に

なることが多いです。既に実装している人がいるので影響がないように

無理矢理な構造で妥協してしまうことが...そしてその無理をした構造が

後で運用や仕様変更、次期開発、新システムへの移行でどれだけの負の要素と

なることやら...

DBFluteはDB設計者にも優しいO/R-Mapperでありたいと考えております。

(実際に今自分はDB設計と開発が並行するProjectでDBFluteを大活躍させております)





こうしてみるとDBFluteは、理想のO/R-Mapperではありません。

現場の問題を解決することに注力しています。

現場の開発が「理想」ではないので、理想のO/R-Mapperは現場に合わない。
UujiとS2Daoの関係、UujiとDBFluteの関係、今後どうなるかわかりませんが、

DBFluteは上記のPolicyを提供するO/R-Mapperであることを貫いていきたいです。

Uujiとはライバルかもしれないし、場合によってはUujiをサポートすることも

考えられます。現状Committer一人でどこまで頑張れるかわかりませんが、

今年たくさん悩んで精一杯頑張っていきます。







後は実は売りにしていきたいのは、10%の外だしSQLの支援。

Sql2Entityをもっと充実していきたいと考えています。
http://dbflute.sandbox.seasar.org/ja/tips-sql2entity.html