「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

プログラムというのは、同じ処理をする場合でもいろいろな書き方ができます。
全部の処理をまとめて書くこともできますし、処理ごとに関数を分けて整理しておくことも可能です。
プログラムの書き方はたくさんあるのです。

ですが、皆が皆、好き勝手に作っていたら、他の人が作ったプログラムの中身を見るのが大変ですよね。

そこで、いろんな人たちが「プログラムの中身はこんな構成にしておけば分かりやすいんじゃね？」な提案をしています。

その中で比較的、世の中に受け入れられたのが「MVCモデル」です。

あくまで「こんな構成にしておけば分かりやすいんじゃね？」な1つの方法論です。
一般的に良しとされてはいますが、絶対の正解では ありません。
ご注意ください。

MVCモデルでは、プログラムの中身を

・モデル（Model）：表示や入力に関連しない処理
・ビュー（View）：表示や入力に関する処理
・コントローラ（Controller）：ビューとモデルの橋渡し役

に分類して作ります。



例えば、そうですね。
データベースからデータを持ってきて画面に表示する「ピヨピヨプログラム」が あったとしましょう。
このプログラムの処理は

１．データベースからデータを持って来る処理
２．データを画面に表示する処理
３．「１．」と「２．」を動かす処理

の3つに分けられます。
そして、それぞれの処理を

関数A：データベースからデータを持って来る処理をする
関数B：データを画面に表示する処理をする
関数C：関数Aを動かして、その後で関数Bを動かす

のように関数化して、関数Aはモデルのところに、関数Bはビューのところに、関数Cはコントローラのところに置きました。
これがMVCモデルに基づいた作り方です。

蛇足ですが、例えば

関数X：データベースからデータを持って来て画面に表示する処理

を作ってそれを動かすだけでもピヨピヨプログラムとしては完成です。
ですが、この作り方はMVCモデルでは ありません。
MVCモデルと言ったら、モデルとビューとコントローラを分けるのです。

MVCモデルのメリットは「（ある程度）整理されて分類されている」ことです。
そのため、はじめて見るシステムでも中身を推測しやすいです。
例えば「○○の処理は表示に関する処理だからビューの中身を見れば良いのかな～」と推測しやすくなります。

また、それぞれ（モデル、ビュー、コントローラ）は独立しているのが普通ですので、分業もしやすくなります。
Webデザイナーさんがビューを変更している間にプログラマさんがモデルを直す、といったことも（理屈上は）できますよ。

一方のデメリットは「実は正解がないこと」これに尽きるでしょう。
良くも悪くも、あくまで「MVC『モデル』」なのです。
例えば「××の処理はモデルに入れるべき？それともコントローラかな？」と処理自体は決まっていても、その処理をどこに入れるかで悩むこともあるでしょう。
私はいつも「これ、処理自体は簡単だけど、どこに書けばいーのよ？」と悩みます。
また人によって意見も異なると思います。
そこら辺の足並みを揃えるのが面倒と言えば面倒ですね。