CatalystのModelの話

「なんでＭＶＣなんて使うの？」という牧さんの記事には全面的に賛成なわけですが、ここでCatalystを出してくるんだったらひとつDISっておかないといけないものがある。

Catalyst::Model::DBIC::SchemaとかCatalyst::Model::Jifty::DBIとか、O/Rマッパをそのままモデルにしちゃってるヤツだ。
自分でも書いておきながら何を、と思わんではないけれど、MVCのキモは、Mで起こっていること、Cで起こっていること、Vで起こっていることをそのまま相手に見せてはならない、ということ。

CatalystのCはMの要素とVの要素を併せ持たされてしまうことが多いわけですが、MVC的には、ふつうの人がC（やV）でやっていることのほとんどはMの中に戻してやらないといけない。O/RマッパはあくまでもMのなかでこっそり使うものであって（現代的にはMMVCパターンの一方のM、とでも言うべきもの）、ほんとはCやVのなかで見えていいものじゃない。

だって、CやVのなかで見えていたら、CDBIからDBICへの移行のときのようにO/Rマッパを変えたくなったとき、CやVまでいっしょに変えないといけなくなるでしょ？　それじゃMVCを使ってる意味なんてないわけですよ。それっぽく見せかけているだけで、実質的にはモノリシックなCGIを適当にファイル分割したのといっしょですもの。レベル的にはみんながよくDISっているあのお方と大差ないのです。

もちろんRailsとかJiftyのように、最初から部品の取り替えなんて考えてないよ、というフルスタックなフレームワークならそれもありでしょう（まあ、JiftyではMason→TDという切り替えがあったわけですが）。でも、Catalystの場合、そもそもはMaypoleをもっとプラガブルにしたい、というところから始まったはず。なのにMがあれであんな使われ方をしていたら、浮かばれないよねえ、というか、やったのは本人だからあきらかな設計ミスですわな。

まあ、その辺わきまえたうえで、C::M::DBIC::SchemaからとってきたResultSetを（C経由で）さらに別のMに放り込んで整理する、ってのはひとつの折衷案としてアリだと思いますし、もうMなんかいらねーよ、全部Cでやっちゃうよ、というのもひとつの折衷案としてアリだと思いますが、無自覚にCPANにあがっているMを使うのはそろそろやめた方がいいんでないかな。

――という話をCatalystConでしようと思っていたんですが、まあ、いいや。次のネタ、考えておくことにしよう。