Catalyst について雑感

mod_perl での Catalyst の設計・挙動を調べたときのメモです。

• Catalyst::Manual::Internals におおまかな処理の流れが書いてある。「still developing rapidly」と書かれているとおり，必ずしもこの通りでもない。
• 駆動部の具象は Catalyst::Engine::* に切り出すことで，Catalyst HTTP サーバや CGI.pm や mod_perl の差異を吸収している。
• mod_perl 2.0 でのセットアップの仕方は Catalyst::Engine::Apache2::MP20 に書いてある。ここを見るとどのように駆動されるか類推できる。
  • ModPerl::Registry や ModPerl::PerlRun で駆動する（非推奨）場合，スクリプト側で MyApp->handle_request(Apache2::RequestUtil->request); と書く必要がある。
  • 一方 PerlResponseHandler として駆動する場合，
    • mod_perl 2.0 では，sub handler : method {} がハンドラとなる。
    • ハンドラで shift->handle_request(@_); している。
    • Catalyst->setup_engine() でこのハンドラがインストールされる。
    • Catalyst->setup_engine() は Catalyst->setup() つまり MyApp->setup() から呼び出される。
• 処理の流れは綺麗に設計してあるが，それの呼び出しの仕方は意外に分散しており，追いにくい*1。フレームワークが背負っている。

調べながらつらつらと考えたこと。

• Catalyst といえば，一般にはモデルやビューの生成ヘルパスクリプトやテスト用サーバがあって，アプリを作るのが楽，という印象。
• 設計の思想としてかどうかは不明だが，プラグインアーキテクチャやディスパッチャへの自動登録機能により，粗結合*2となっている。
  • そもそも Perl は，C++ や Java と比べて，粗結合向きだし。
  • これを推し進めると，Catalyst を DI コンテナに fork できるのでは，と思った。YAML や JSON とかで依存性記述したり。
  • と思ったら，同じような発想の人（CatalystとDIが繋がりそうなメモ - shckorの日記）がいた。
• Catalyst はプロトタイピングに使うには惜しいくらい便利で柔軟で頑丈に設計されたフレームワークになっている。
• でも仕様がどんどんかわっていくので怖くて実サービスではまだ使えない。

とくに最後について，あくまで個人的な考えです。扱う案件のレベルによっては使えるでしょうし，息の短いβプロダクトやプロトタイピングには向いていると思います。

*1:一応，Catalyst.pm と Catalyst/Engine.pm を熟読すればそこそこは追えるのですが。でもその中でも誰がいつどう呼び出しているかを知るのが難しいです。

*2:よくある Web サービスにおける密結合・粗結合の定義とは違い，モジュール間の結合度の話です。ってこういう用法は認められるのかな。