Hatena::Groupcatalyst

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

2008-04-23

モデルを拡張していくための仕組み

モデルを拡張していくための仕組み - dann@catalyst を含むブックマーク はてなブックマーク - モデルを拡張していくための仕組み - dann@catalyst モデルを拡張していくための仕組み - dann@catalyst のブックマークコメント

モデルを切り離すことの意味として、

  • Testabilityを高めるため
  • Webのコンテキスト以外の再利用ができるようになる

と書いたのだけれど、モデルを切り離したいというのは、それだけが理由ではなかったりします。

モデルを切り離した後には、もう少し先があるんじゃないかなぁと思っていて、スライドの付録に書いていました。WAFとは独立させて、POPOのモデルだけを拡張していけるための仕組みがあったら、モデルを資産として残せる(これは幻想かもしれませんが)、もしくはモデルの後からの拡張が容易になるんじゃないかなぁと思っていました。

拡張する方向としては、以下の二つがあるかなぁと思いました。

  • プラガブルにモデルの機能を追加する仕組み
  • モデルから横断的な関心毎を切り離して、任意の箇所に適用する仕組み

POPOに上記の二つの拡張する仕組みを提供できると、Webの世界と切り離して、モデルだけを育てる仕組みができ、モデルを資産として残していける部分ができるんじゃないかなぁと思っていました。そうでなくても、拡張性の高いモデルを作れる可能性がありそうです。

1つ目。モデルをプラガブルに拡張するための仕組み。id:YappoさんのClass::Component。これはいかにもLLらしい面白いコンポーネントだなぁって思ってます。これはいかにもPerlっぽくて、絶対Javaの世界にはない話なんですよね。モデルをプラガブルに拡張するための仕組みがあれば、モデルを資産として残せる部分もでてきそうです。

2つ目。Javaな世界では、Caching、Transaction、Loggingなど、モデルの横断的な関心毎を切り離して、モデルの外からコードを付与してやる仕組みが流行りました(実際成功したのは、Transaction、Loggingくらいなわけですが。)Transactionなどが、POPOのコードから消えるので、POPOそのもののTestabilityが高くなるわけです。これはこれで価値がありますね。

Class::Component, Moose, (Class::MOP)は上記を実現できる可能性のある面白いライブラリだなぁと思っていて、とても注目しています。

Catalystかわいいよ!

 Catalystかわいいよ! - dann@catalyst を含むブックマーク はてなブックマーク -  Catalystかわいいよ! - dann@catalyst  Catalystかわいいよ! - dann@catalyst のブックマークコメント

自分のスライドも、「CatalystのModel」はいらないと一見DISってるようになってるけど、自分の場合、全然WAFはCatalystでOKなんじゃないかと思ってるということだけ、一応かいときたい!

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

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

プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*)

 プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*) - dann@catalyst を含むブックマーク はてなブックマーク -  プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*) - dann@catalyst  プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*) - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/charsbar/20080423/1208920975#seemore

wrap some prepare_* or finalize_*

If your functionality needs to wrap some prepare_* or finalize_* stages, you won't get around a plugin.

Catalystのマニュアルで言われていた、「wrap some prepare_* or finalize_* stages」っていうのは、charsbarさんが書いている以下の問題のことなのかな。

prepare_*とか)にNEXTで機能を突っ込むときにロード順を気にしないといけない

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

けど、ロード順に副作用があるから、実装見ないと使えないというのは「プラグイン」としてはいまいちだよねというのはわかる気がする。

ただ、実際問題プラグインも5-6個くらいしか使わないわけで、そう考えるとそんなに気にならないんじゃないかって気がするのだけれど。そんなにたくさんのプラグインを使うことが前提になってるような気もしないし。

CatalystCon#1資料-Catalystからモデルを切り離せ

CatalystCon#1資料-Catalystからモデルを切り離せ - dann@catalyst を含むブックマーク はてなブックマーク - CatalystCon#1資料-Catalystからモデルを切り離せ - dann@catalyst CatalystCon#1資料-Catalystからモデルを切り離せ - dann@catalyst のブックマークコメント

slideshareのほうにアップ。

http://www.slideshare.net/techmemo/catalyst-367905/

後で。

# slideshareだとやっぱりスライド変換途中でレイアウトが少し崩れるね。

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 という感じで。