catalystでMVCでモデル分離オレオレまとめ

Perl Catalyst

出来の悪い人がCatalystでモデル分離を勉強した仮まとめ。
嘘、大げさ、紛らわしいことが入り乱れてます。

何故皆モデルをコントローラから分離しろ、コントローラにロジックを書くなと言うのか

catalystではコントローラで$cが使えるが、これはuriリクエストがあったときしか使えない。
つまりコントローラに$cを使いまくったロジックを書いてると、その部分をテストするのに、ブラウザからしかテストできなくなってしまい、テストの自動化ができなくなるから

モデル分離の理由は？

テスタビリティを上げること（テストの自動化）、コマンドラインやスクリプトからもモデルに書いたロジックを使いたいから


Q.コントローラに書いたロジックを使いたいならwgetなりcurlなりすればいんじゃね？
A.テストでカバーできるのが実行結果だけになる。ロジックの過程がチェックできない。他にも、コントローラに書いたら外部公開されるとか、1日1回しかしないような処理をメモリ消費してまでコントローラに載せる意味がわからない、とか

なんでAPIっていうのを作るの

モデルに実装したロジックを、catalystのコントローラからも、スクリプトからも、コマンドラインからも呼びたいから
こうすると、コントローラからは$c->model('DBIC::User')って呼んでたものが、スクリプトからも呼べるようになるんです。つまり、いちいちブラウザからカチカチやらなくてもテストできるんですよ

APIじゃなくてModelにロジック実装したらいいんじゃないの？

上記に反する。
あと、Userモデルだけで処理が完了するならそれでもいいけど、例えば他にBookってモデルがあったとして、UserにもBookにも操作をするような処理が出来たら、それがUserに実装されてるって気持ち悪くない？

ResultSetにメソッド生やす手法（参考リンク）を使ってるんですが

メソッドを書く先がSchema/User.pmからAPI/User.pmになったと思ってください
あと、schemaはあくまでテーブルの構造を書くところなので、ここにロジック書くのって気持ち悪くないですか
（リンク先のような、ResultSetManagerを使う手法が悪いと言っているのではない。むしろ俺が使いまくっていた手法）

中身スッカスカでほとんど同じモデルが沢山できるんで無駄っぽいんですが

この本の方法だとしょうがない。ググったら同じ事言ってる人がいたからそっち当たってみるのもよし？
（もしくは自動化できそう。俺が思いつくのはレガシーな方法だけど）

  • モダンPerl入門への突っ込み
    • 説明の誤字脱字よりもコードの誤字脱字が目立つ
    • ストレージがDBというかRDBMSであることが前提になっている
      • まぁ普通変わることはないけど。が、どんなストレージだろうと統一されたインタフェースで操作できるようにどっかにその処理を書いたほうがいいのでは
      • 例えば、ストレージがDBだろうがcsvだろうが、find(4)って打ったら4番目のデータが取得できる、みたいな
      • ここではcatalystとDBって事で話進めてんだよこのKY
      • 実装するとしたらWAFとかモデルとかより上の階層で


大体こんなところ。






何でこんな駄文書いてんの

  • 備忘録
  • ネットに書くとperlのえらい人がミスを指摘したり、アドバイスくれたり、DISったりしてくれるかもしれないからです

えらい人がこんなところ見るの

  • 痛いところを。書いたら何か間違って見に来るかもしれませんが、書かなかったら目に触れる機会は皆無ですね