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(ビュー)・・・画面の生成。テンプレート。

Comments

  • コマネチ より:

    ふんわりと理解できたが、異常系の場合もこのマンガ方式で解説して欲しい。

  • 通りすがり より:

    目から鱗でした。ありがとうございます!

  • hamasan より:

    MVCモデルを簡潔にわかりやすく, しかも漫画で表現しているところについ, おぉーっと声をあげてしまいました.
    面白かったです, thanks : )

  • […] MVCモデルの概念を漫画で解説してみる | hijiriworld Web […]

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

  • […] このサイトがすごく分かりやすかった! MVCモデルの概念を漫画で解説してみる/ […]

  • ちょうどMVCについて説明しなければならないところでした。
    画がとてもわかりやすくすんなりと入ってきまいた。
    参考にさせていただきます。

  • どらごん より:

    この絵、わかりやすくて面白かったです!MVCを理解していない人に説明する時には便利そうですね。

    http://digi-cyber.net

    • hijiri より:

      どらごんさん

      コメントありがとうございます ^^
      そう言っていただけると嬉しいです。

      拙い棒人間劇場で恐縮ですが…(笑

      • どらごん より:

        いえいえ、棒人間が一番分かりやすいです!3minutes Networkingというサイトで慣れ親しんでいたもので(笑

        私はここ最近からWPやPHPの勉強を始めたのですが、PHPは手元にテキストがあったという理由からCodeIgniterを使っています。
        管理人さんがCake PHPを進める理由は、何かあるのでしょうか?

        • hijiri より:

          フレームワークを採用する基準は、開発するシステムの規模と、開発手順に依ります。
          CakePHPは、MVCモデルに厳格で、PHPやSQL文を自前で書くことは推奨されていません。よって、フレームワークの仕様に合わせた設計が必要になります。
          一方、CodeIgniter(CI)は、MVCモデルや手順に囚われない自由度があり、PHPやSQL文を自前で書くことも許容されています。よって、PHPを知っていれば、すぐに開発が可能と言えます。
          一般的に、CIは小規模向き、CakePHPは小規模から大規模向きと言われています。規模というのは、機能的な話ではなく、開発人数という捉え方だと思っています。
          1人で開発するのであれば、自由度の高いCIは便利ですが、複数人で開発することを考えると、属人的になってしまう自由度の高さより、厳格にルール化された中で開発した方が効率的ということですね。
          私が主にCakePHPを採用している理由は、扱っている案件にマッチしているからです。
          案件が異なれば、採用するフレームワークの変更を検討することもあると思いますが、CakePHPはわりと守備範囲が広いので、気に入っているという感じです。

よちよち.rb 第5回に参加してきました | issy_s16.diary へ返信する コメントをキャンセル