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