イントロダクション

4月より転職してエンジニアとして働いています。
業務ではRails、フロントはVue.jsを使用した開発に携わらせてもらっています。
タイトルの通り、MVCモデルについて実務を通して思ったことを書いていくのですが、せっかくなので、自分の知識の復習も兼ねてMVCモデルとはというところから話してみたいと思います。

MVCとは

ググればめちゃくちゃ記事出てくるのと、本筋ではないのでさっくりと書かせていただきます。
M（モデル）・・・データを加工する場所
C（コントローラー）・・・データをモデルやビューに受け渡す場所
V（ビュー）・・・見た目を整える場所

それぞれ上記のように役割を明確にすることで、開発をしやすく、かつ保守なども行いやすいというメリットがあります。
実際、僕のような業務に入り始めて間もないものでも、このMVCモデルのおかげで開発に携われるようになっています。

レストランで例えると

キッチン・・・モデル。データ（食材）を美味しい料理に加工する
ウェイター・・・コントローラー。加工された料理をお客様のもとに運んだり、お客様から受け取った注文をキッチンに伝えたりする。
ビュー・・・料理そのもの。見た目整えればお客様の食欲そそる（UI向上）。

自分なりにMVCモデルについてなにかわかりやすい例えないかなと考えた結果、レストランめっちゃわかりやすいやん！
って思ったけど、調べてみたら結構これも記事にされていた（本当に自分で考えましたよ！）。

MVCのメリットって？

さっきも書きましたけど、M・V・Cそれぞれで明確に役割を持っているので、開発しやすい。
また、モデルだけ改善させたいのよね〜とかいうときに改善させやすい。

実務で扱っていてエラーが起きたとしても、どこでエラー起きているのか判断しやすいというのもメリットかと感じています。

MVCのデメリットって？

現状、Railsしか経験していないため、もしかしたらRailsに限ってしまうかも知れませんが、
モデルで行うべき処理をコントローラーで行えてしまうというのが今の所僕が感じる最大のデメリットかなと感じています。

本来、データの加工などはモデルで行うべきとされていますが、Railsのその自由度のおかげでコントローラーで書いても正常に動いてしまいます。
その瞬間はそれで良いのかも知れませんが、コントローラーをファットにしてしまうと、その後機能を追加しようとしたときにボディブローのように効い来ている場面を見かけます。

そして、いざどうしようもなくなったときにコントローラーをリファクタリングすることになり、結局モデルにビジネスロジックを移行するという作業が増えてしまう（もしくは複雑になりすぎて手が出せないということになりかねない）。

まとめ

一言でまとめると「取り返しがつかないことになるかも知れないので、コードを書くときはMVCの役割に沿った場所で書くべき」なのだと実務を通して感じております。