初めに
ここ1年くらいの間で、案件探しで聞く頻度が多かったMVCについて、実務経験がほとんどないので自分の言葉で説明できるようになるべく、調べてみました。
MVCとは
M：Model。データの処理を行うことが多い。表示や入力には関連しない。SQLを扱う。
V：View。表示や入力に関する処理。多くの場合、HTML。
C：Controller。ViewとModelの橋渡しをする。
「MVCモデル」と言っていたら、プログラムの中身をこの3つに分類して作る考え方・手法のことを指しています。
具体例を挙げてみます。
『データベースからデータを取得して画面に表示する』
というプログラムの場合を例にします。
このプログラムをMVCに分けて作るとすると、以下のようになります。
M：データベースからデータを取得する処理をする
V：データを画面に表示する処理をする
C：Mの処理を呼び出し、その結果をVの処理を呼び出して渡す
このように、プログラムを分類して組み立てるのが「MVCモデル」です。
この分かれている点にメリットがあるとされていて、M/V/Cが独立していることで、分担作業をすることが出来ます。
例えばViewは画面表示（見た目）の部分なので、専門性の高いデザイナーさんにデザインしてもらい、その間にデータアクセス等ビジネスロジックを構築しておく、ということも出来るというわけです。
MVCのデメリット
プログラムを「MVC」の3つに分けることが「MVCモデル」だと述べましたが、この考え方自体がデメリットと言えます。
モデルはあくまでモデル、であり、数学のように答えが一つというわけでは無いようです。
言葉で理解するのは難しくなくとも、MVCモデルに沿って分けて書くことを考えると、「どこに書くのが正解なんだろう」と悩んでしまう時が来ると思います。
ただ、細かいコーディング規約やルールは現場毎に都度確認し、レベル感を合わせていくしかないのかなと思います。
終わりに
MVCについて調べてみました。
MVCモデルを採用していると、何か不具合が起きたときにも修正箇所のアタリを付けやすくもなりますね。
もし、MVCから外れたところにコードを書いてしまうと、原因究明に時間がかかることにも繋がります。
MVCとは言わずとも、画面・ビジネスロジック・データアクセスの各ソースを分けて書いていたことがある方もいると思います。
書いた人も新卒の頃の会社のあるプロジェクトではMVCぽく書いていましたがMVCと言っていた記憶が無く。。。
今回調べたことで、MVCについては知ることが出来ました。
今後は実務経験を積んで慣れていきたいと思います。
