MVCのお勉強。太ったモデルと痩せたコントローラ

下の2つの記事を読んで、すこし理解が深まったような気がしているのでメモ
Web アプリの MVC 設計まとめ :: もやし日記
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

CakePHPを使ったMVC設計のベストプラクティスを読んで、ビジネスロジックはモデルに置くべきだと認識した。コントローラーをシンプルにしておけば処理の流れもわかりやすいだろうと。

特定のモデルに大量のメソッドが集中したり、どのモデルがどういうトランザクションを担当するのかが分かりにくくなってきて、コードの可読性は下がり、重点的にテストすべき場所も分かりづらくなってきます。
Web アプリの MVC 設計まとめ :: もやし日記

確かに機能が増えてモデルが多機能になりすぎることはありそう。
実際1つのカラムの値を取得したいだけなのに、多機能なインスタンスを作らないといけないってのもメモリーの無駄遣いかも。
あるコントローラでしか使われていない機能があるってのも気になる。

次の間違いは、Skinny Controller, Fat Modelが最良だと信じている点。
Fat ModelはFat Controllerと同様にテストはしにくいし、理解しづらくなる。ロジックはそれぞれ適切なところで実装すべきで、Fatなのはやはりよくないのです。
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

ふむふむ。やはり過ぎたるは及ばざるが如しですな、と脳みそ停止しきってるくせに理解したふりしてみる。
コントローラーとモデルの両方をテストしないと確実じゃないってことになったら、そのテストってなんなの？って感じはするな。

追記:一昔前のフレームワークなら、ControllerはWebのAPIに依存していてテストしにくいというのもあってControllerからロジックを追い出せということがよく言われてきましたが、いまどきのちゃんとしたフレームワークは最初からControllerもテストできるように考慮されています。
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

そもそも、コントローラーにロジックを置かない理由の1つがテストしづらいからだったの？
他にはどんな理由があるんだ？コントローラはロジックを置くとこじゃないってのが1番の理由だと思ってたんだが…どうなんだろう。

きっちりテストできるならどこにあってもいいってことなら、それはそれでシンプルな考え方でいいかも。で、実際にそうしてみたら、テストのやり方が煩雑になって、やっぱりどっかにまとめようぜってなりそう。

今日の俺POINT
・基本コントローラーはシンプルに。
・Fat Modelには気をつけよう
・なんでもFatは良くないよ
・Serviceってやり方もあるらしい
・2008年と2009年の記事なんで、今は変わってるかもしれん。

コントローラにたった1つだけあるドクロマークのボタンを押すと、太ったモデルがセクシーに踊りだすという解釈でいいであろうと思われる。