S2JDBCが生産性10倍っていうけどさぁ
何をもって10倍と言うのか、、、と思ったんだけど、
何に比べて生産性が10倍かというとJava標準のJPA(Java Persistence API)に対してです。
相手が悪い。
JPAと比べてどうするのって思う。
S2Daoと比較することで、S2DaoのユーザをS2JDBCに移行させることにどれほど意味があるのかは疑問です。それで、Seasar2のユーザが増えるわけではないから。
これまで、Seasar2のユーザではなかった人たちが、S2JDBCの生産性の高さに引かれて新規ユーザになってくれるのが望ましいシナリオではないでしょうか。
JPAはJavaの標準だし、比較対照としては妥当だと思います。標準だけど、生産性は高くない。一見簡単そうだけど、はまりどころが多くて結局生産性は悪くなる。だから、生産性を比較しやすいって「ずるい」計算もあります。
jdbcManager.callBySql("{? = call myproc(?, ?)}", dto).call();
さすがに、これはダメだろー。
生でストアド呼び出してるのと、変わんないじゃん。
生でストアド呼び出してるのと、変わらないからいいんですよ。何をやっているかが一目瞭然。そして、余分なJDBCまわりの処理はする必要がない。
のように呼び出せたほうが、スマートに見えるかもしれないけど、そうするとデータベースメタデータを取りにいくか、規約を設けるかして、もとの"{? = call myproc(?, ?)}"を組み立てる必要がある。
jdbcManager.callProcedure("myproc", dto);
データベースメタデータをとりにいくのは、パフォーマンスに問題がでるので、最近はS2Daoも取りに行かない方向に向かっています。規約は、一見便利だけど、間違えたときにどうしてもわかりづらくなる。
今回は、明確に「脱CoC」を打ち出しています。明示的に書くことで多少書く量が増えても、一目瞭然でトラブリにくいならそのほうがいいと思っています。
> 90%のSQLを自動生成する
自動生成と言っても、JavaでSQLを書くんでしょう？
私は、このJava式SQLが、いまだにダメで。
新人の時に、Hibernateで大失敗して以来、トラウマで（←自分が悪いｗ）
何でもJavaで書こうとすればきっとはまると思いますよ。でも、S2JDBCはそうじゃない。
- from()
- join()
- where()
- orderBy()
- limit()
- offset()
でかける範囲に限定して自動でSQLを生成し、それ以外は、明示的にSQLを書けというスタイルです。
上記の6つだけで構成されているなら、レビューはしやすいと思いますよ。
