ワシはワシが育てる

週刊少年ジャンプと任天堂のゲームが三度のメシより好きです。

個人的に考えるビジネスロジックをModelに書く意味

一昔前にはMVCモデルではビジネスロジックをコントローラーに書くのかモデルに書くのか議論になりましたが、おそらく潮流としてモデルに書くのが暗黙の了解になっているかと思います。

とはいえMVC覚えたてのうちはどうしてもその意味がわからず、ControllerをFatにしてしまう傾向があります。(まさに自分もそうでした!)

多かれ少なかれ案件をこなしていくと自ずとその意味もわかってくるのですが、備忘録がてら書いてみることにしました。

1. コントローラーをスリムにすることでURL(画面)のロジックを簡潔にする

毎日一つのアプリケーションを何時間もコーディングしているのなら、URLルーティングのロジックは自然と頭のなかにあるでしょうが、複数案件を同時にこなしたり、継続的に保守をする場合はどうでしょうか。
僕の場合、何ヶ月もブランクを開けた状態で一つのコントローラーに数百行もロジックがゴリゴリ書かれているのを見ると、フローを理解するのが相当難しく感じます。さらに言えばモチベーションも失われます。

モデル周りのロジックにそれらしい意味合いのメソッド名がついてれば、「ここはこういう処理をしてるんだな」と察して、ひとまずURL周りのロジックを簡潔に確認できるのでタスクへの復帰が楽になります。

2. 機能を分割してテストをすることで、問題の所在を明らかにする

コントローラーで複雑に書かれたロジックを紐解くよりも、モデルで細かくロジックを分割し、それぞれが正常動作を担保している状態で保守をする方が楽なのは想像に難くないと思います。

一旦ロジックをテストで固めてから、コントローラーでフローを描く方がトラブルなく開発を進めることができますし、場合によってはその方が開発速度が上がることもあります。

随分前から言われている「Fat Model, Slim Controller」というのは場数を踏めば踏むほど有り難みを感じてきます。