MVCモデルの概念を漫画で解説してみる

ユーザーインタフェースをもつアプリケーションソフトウェアの多くは、「MVC」モデルに基づいて設計されています。
MVCでは、プログラムを、Model(モデル)、View(ビュー)、Controller(コントローラ)という3つの要素に分割し、お互いに呼び出し合って処理が実行されていきます。

この概念を漫画で表現したら分かりやすのではないかと思い、トライしてみます。

設定

MVCモデルで設計された「なにかの申し込みシステム」があるとします。
処理の内容は、なにかの申し込みをしたユーザ情報をデータベースに格納する、だけです。

なにかの申し込みシステムの構成員

第1話 – なにかの申し込みシステムの日常

なにかの申し込みシステムの処理の流れを覗いてみましょう。

おや?ユーザが申し込みにやってきましたよ…

このように、モデル、ビュー、コントローラは、お互いに協力し合いながら処理を行っています。
誰か1人でも欠けたら、このシステムは動きません。

ここで重要なのは、3人が3人とも自分の仕事だけに集中し、他の人の仕事にはいっさい関与していないという点です。

ビューは受付業務を行います。申し込みボタンが押されたらコントローラーが勝手にやってきます。そしてコントローラに処理を依頼しますが、具体的な処理の内容は知りません。
コントローラは処理を行います。その処理の中に「データベースに格納せよ」という内容があったらモデルに依頼しますが、どのようにデータを格納しているのかは知りません。
モデルはデータを格納します。それまでコントローラがどのような処理をしたのかは知りません。もちろんビューがなにをしたかなど知るよしもありません。

これがMVCモデルです。わかったかな?

第2話 – なにかの申し込みシステムの成長

ある日、なにかの申し込みシステムを作った開発者は、このシステムを改修したいと考えました。

改修ポイントは3つ。

① データベースを最適化して構造を変えたい
② インターフェースをカッコよくしたい
③ 処理を追加したい

開発者は、モデル、ビュー、コントローラを別々に呼び出し、それぞれの改修ポイントをその人だけに伝えました。

そして翌日…

それぞれ仕様変更が発生したにも関わらず、まったく問題なく処理することができました。

ここで重要なのは、仕様変更をそれぞれの人しか知らなくても問題ないという点です。
他の人の仕事にはいっさい関与しないので、他の人の仕様変更など関係ないのです。

ビューはおしゃれをしていますが、コントローラーはそんなことには気づきません。
コントローラの仕事は増えましたが、他の人は知らんぷりです。
データベースの構造が変わりましたが、相変わらずコントローラはモデルに「これ、登録しといて」と言うだけです。

このように、MVCモデルで設計しておくと、互いに仕様変更の影響を受けにくくて済むようになります。

わかったかな??

第3話 – 開発者の出世

なにかの申し込みシステムを作った開発者は、出世して偉くなりました。
それまでは、モデル、ビュー、コントローラの3人を1人で管理していましたが、もうその必要はありません。
デザイナー、プログラマー、データベースエンジニアという、3人の部下を持ったのです。

そしてまたある日、なにかの申し込みシステムを作った開発者は、このシステムをさらに改修したいと考えました。

改修ポイントは以前と同じです。というか、すべてはこの3つに大別できるはずです。

① データベースをもっと最適化して構造を変えたい
② インターフェースのデザインをもっとカッコよくしたい
③ 処理をもっと追加したい

以前ならば、開発者が自ら、モデル、ビュー、コントローラを別々に呼び出して直接指示を出すのですが、いまは違います。
出世して偉くなって3人の部下ができたのです。

①は、データベース設計が得意なデータベースエンジニアに、②は、インターフェースデザインが得意なデザイナーに、③は、プログラミングが得意なプログラマーにやらせることにしました。

このように、MVCモデルで設計されていると、それぞれ分業が可能になるのです。

なぜなら、MVCはお互いに仕様変更の影響を受けにくいからです。
デザイナー、プログラマー、データベースエンジニアは、他の人に配慮することなく、自分の得意な分野で思う存分仕事ができるのです。

すばらしいですね!

めでたし、めでたし。

おっしまい

Model(モデル)・・・データベースへのアクセス、SQLコマンドの送信、レコードの取得と管理。
Controller(コントローラ)・・・プログラムの制御。
View(ビュー)・・・画面の生成。テンプレート。