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で大失敗して以来、トラウマで（←自分が悪いｗ）

2007-10-25 - ぜろ部ー屋？

何でもPerlで書こうとすればきっとはまると思いますよ。でも、DBICはそうじゃない。

from()
join()
where()
orderBy()
limit()
offset()
でかける範囲に限定して自動でSQLを生成し、それ以外は、明示的にSQLを書けというスタイルです。

上記の6つだけで構成されているなら、レビューはしやすいと思いますよ。