http://s2container.seasar.org/2.4/ja/s2jdbc_abstract.html
タイミング的に、今しか言えなさそうなので。
生産性を10倍以上高めることを目標として
何をもって10倍と言うのか、、、と思ったんだけど、
何に比べて生産性が10倍かというとJava標準のJPA(Java Persistence API)に対してです。
相手が悪い。
JPAと比べてどうするのって思う。
（マネージメント層の説得のために、JPAと比べたいのかも知れないけど）
JPAと比べるせいで
「やっぱS2Dao捨てちゃったんだ」って思うのが、私の感覚。
「S2Daoの問題を見直して、S2Daoに比べてこれだけ生産性を高めた」
って言ってくれる方が、S2Daoのノウハウが積み重なった感じがして、嬉しいんだけど。
■INSERT/UPDATE/DELETE系
S2Daoでは分かりづらかった命名規則がなくなった分、
良くなったと思う。素直に嬉しい。
ハマらなくなったし、調べなくて良くなった。
■ストアドの呼び出し
jdbcManager.callBySql("{? = call myproc(?, ?)}", dto).call();
さすがに、これはダメだろー。
生でストアド呼び出してるのと、変わんないじゃん。
（実際そうなんだろうけど）
「?」の数の間違いを検出してくれる機構よりも、
S2Daoと同じ感覚で、
jdbcManager.callProcedure("myproc", dto);
jdbcManager.callFunction("myproc", dto);
ぐらいで、呼び出し文を構築してくれる方が分かりやすい。
だって、「?」の数は間違うことはあっても、
Dtoに記述したIN/OUT/IN_OUTは間違わないから、きっと。
あと、個人的には、stored functionは
「return_OUT」を、「戻り値」にした方が、
分かりやすいと思うんだけど。
戻り値にできない（or したくない）理由って何かあるのかな？
■検索系
多分、今回の目玉だろうけど、
肝心のこれで、生産性が上がると思えないんだよね。
> 90%のSQLを自動生成する
私は、このJava式SQLが、いまだにダメで。
新人の時に、Hibernateで大失敗して以来、トラウマで（←自分が悪いｗ）
要は、SQLも分からんのに（SQLドリルが終わってないレベルで）
Javaでホイホイ作ってると、とんでもない実装しちゃうじゃん？
別に、SQLドリルをちゃんと終わっていて、
JdbcManagerが吐くSQLをきちんとイメージしながら作っていれば
間違わないと思うよ？
でも100人開発者集めて、開発をスタートさせたら、
そういうわけにはいかないよね？
だから、limit(10).offset(100)を書かせる。
だから、SQLを書かせる。
どっちにすべきかは、よく考えなきゃいけない。
いまの私の考えだと、後者かな。
あと、SimpleWhereみたいなJava式SQLって、
たぶん、高速に書きたい or 高速にリファクタしたいがために
JavaとEclipseを活かして書くってことだよね？
私自身、高速リファクタの恩恵を受けた経験がないから
まだ良さに気付いていないだけかも知れないけど。
それでも、
SimpleWhereを書くぐらいなら、素直にSQLを書いた方が
SQLをきちんと理解できるし、何より、レビューしやすいと思うんだけどね。
■レビューできない
そうなんだよね、
Java式SQLのソースなんてレビューできないんじゃん。
生のSQLを見なきゃ、レビューできないじゃん。
少なくとも、私の右脳は、Java式SQLから問題を発見できない。
ソースコードを右クリックしたら、SQLが表示されるEclipseプラグインとか、
JdbcManagerの呼び出し箇所を検出して、全てのSQLを表示してくれるツールとか、
そういうのがなきゃ、レビューできない。
（そんなツールが構想に入ってないようだったら、作るよー！）
で、レビューした結果NGだったとして、
それをJava式SQLでどれだけ簡単に修正できるかも、まだよく分からない。
この辺りは今後評価していきたい。
