ユーザーインタフェースをもつアプリケーションソフトウェアの多くは、「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
ふんわりと理解できたが、異常系の場合もこのマンガ方式で解説して欲しい。
目から鱗でした。ありがとうございます!
MVCモデルを簡潔にわかりやすく, しかも漫画で表現しているところについ, おぉーっと声をあげてしまいました.
面白かったです, thanks : )
[…] MVCモデルの概念を漫画で解説してみる | hijiriworld Web […]
[…] MVCモデルの概念を漫画で解説してみる […]
[…] このサイトがすごく分かりやすかった! MVCモデルの概念を漫画で解説してみる/ […]
ちょうどMVCについて説明しなければならないところでした。
画がとてもわかりやすくすんなりと入ってきまいた。
参考にさせていただきます。
この絵、わかりやすくて面白かったです!MVCを理解していない人に説明する時には便利そうですね。
http://digi-cyber.net
どらごんさん
コメントありがとうございます ^^
そう言っていただけると嬉しいです。
拙い棒人間劇場で恐縮ですが…(笑
いえいえ、棒人間が一番分かりやすいです!3minutes Networkingというサイトで慣れ親しんでいたもので(笑
私はここ最近からWPやPHPの勉強を始めたのですが、PHPは手元にテキストがあったという理由からCodeIgniterを使っています。
管理人さんがCake PHPを進める理由は、何かあるのでしょうか?
フレームワークを採用する基準は、開発するシステムの規模と、開発手順に依ります。
CakePHPは、MVCモデルに厳格で、PHPやSQL文を自前で書くことは推奨されていません。よって、フレームワークの仕様に合わせた設計が必要になります。
一方、CodeIgniter(CI)は、MVCモデルや手順に囚われない自由度があり、PHPやSQL文を自前で書くことも許容されています。よって、PHPを知っていれば、すぐに開発が可能と言えます。
一般的に、CIは小規模向き、CakePHPは小規模から大規模向きと言われています。規模というのは、機能的な話ではなく、開発人数という捉え方だと思っています。
1人で開発するのであれば、自由度の高いCIは便利ですが、複数人で開発することを考えると、属人的になってしまう自由度の高さより、厳格にルール化された中で開発した方が効率的ということですね。
私が主にCakePHPを採用している理由は、扱っている案件にマッチしているからです。
案件が異なれば、採用するフレームワークの変更を検討することもあると思いますが、CakePHPはわりと守備範囲が広いので、気に入っているという感じです。