Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-04-23

Catalystの良くないところ

 Catalystの良くないところ - dann@catalyst を含むブックマーク はてなブックマーク -  Catalystの良くないところ - dann@catalyst  Catalystの良くないところ - dann@catalyst のブックマークコメント

CatalystConででたDISの殆どは、$c依存の強さ、Plugin、モデルのWAFへの依存の3点なんじゃないかと思った。けれど、$c依存の強さ、Plugin、については、実際大して問題ないんじゃないかなぁと思った。

というのは、

$cの依存の強さ」については、VC$cに依存していても、フレームワークから切り離して、VC使うことがないので、依存していても気にならないから。Vだけをテストしたいという要求も特になく、それでいいんじゃないかなぁと思ってしまう。だから、VCはフレームワークにある程度密に結合してても、いいんじゃないかと思う。

Pluginについては、プラグインのロード順に副作用があるのとアプリケーションワイドに機能を追加してしまうところが、気持ち悪さの原因なんじゃないかなぁと思った。

これは確かに気持ちが悪い。ただ、実際問題使うプラグインそのものがそんなに多くないわけで、そんなに気にすることないんじゃないかなぁという印象なんだけれど、そういうもんでもないのかなぁ。

仮に20個程度のプラグインをロードして、バッティングする組合わせが複数のセットで考えられますとなると、頭が痛い問題かもしれない。ただ、実際問題使うプラグインは数個と限られているわけで、どちらのケースも問題にならないんじゃないかと思った。ロード順を気にしなきゃいけないというのは正直どうかとは思うけれど、実用上問題ないんじゃないかってこと。

で、モデルについて。モデルについて切り離したほうがいいと思っているのは、単体テストのしやすさ、速度の問題と、他のコンテキストからの利用がありうるケースが多いから。逆に、これが問題にならない規模のアプリケーションでは、あえてモデルを切り離すことのメリットがないわけで、密に依存していても大きな問題にはならないんじゃないかと思う。

BaysideBayside2008/04/24 12:30すごく同感です。Java の struts と PHP の Zend Framework に明示的なモデルがないのは、フレームワークは VC だけ用意しておけばOKということなのかもしれませんね。

danndann2008/04/24 22:57仮にWAFがMを提供するにしても、WAFにMが依存しない形でもMを使えるような形でも提供するべきだろうなぁとは思います。要するに、WAFのM --> POPOのM という感じで。