ディープロ
2019年5月11日Ruby on RailsのMVC構造を銀行に例えて解説してみた
Ruby on Railsは素早くWebアプリケーションを開発することができるフレームワークです。本記事では、Ruby on Railsで採用されているMVC構造を身近にある銀行に例えて解説。
Ruby on Railsは素早くWebアプリケーションを開発することができるフレームワークです。本記事では、Ruby on Railsで採用されているMVC構造を身近にある銀行に例えて解説します。
【こんな方におすすめ】
・Ruby on Railsを学びたい方
・MVC構造のイメージが掴めない方
・プログラミングスクールを検討している方
【目次】
1. 窓口係はコントローラ（Controller）
2. 出金係はモデル（Model）
3. 通帳明細はビュー（View）
■話し手
ディープロ 代表 野呂 浩良（のろ ひろよし）
■聞き手
StartGate 永田 拓也（ながた たくや）
初学者の方でもわかるように身近な銀行に例えて解説していますので、MVC構造をイマイチ理解できていない方に役に立つ話になっています。
窓口係はコントローラ（Controller）
今回はRuby on RailsのMVC構造を銀行に例えて解説します。
よろしくお願いします。
MVCとはModel(モデル)というデータを引き出す役割、View（ビュー）という画面に表示する役割、Controller（コントローラ）というそれらを管理する役割、これらの頭文字を取ってMVCと呼びます。永田さんがWebアプリケーションにアクセスする際は、ご自身のコンピュータのブラウザからURLやリンクボタンを押してアクセスします。この際に通信が発生します。この通信をサーバが受け取り、役割に応じて処理が順番に流れ、処理結果がご自身のコンピュータのブラウザに返ってきます。なぜこのような仕組みになっているのかよくわからないじゃないですか？だから、銀行に例えて解説していきます。
はい、お願いします。
まずMVC構造を理解するためには、通信の流れについて概要を理解しておく必要がありますので、簡単に説明します。
・・・通信の流れですか。
インターネットの世界では、ブラウザ上で画面が表示されるまでに2つの流れがあります。1つ目はリクエスト、2つ目がレスポンスです。リクエストは任意のURLで指定のコンピュータへアクセスする流れです。2つ目のレスポンスは、リクエストを元にアクセス先のコンピュータからブラウザに表示するための元になるファイルを送り返す流れです。下図のようなイメージですね。
なるほど。
それでは、MVC構造を銀行の仕組みに例えて解説しますね。永田さんはお金を引き出しに来た人という設定にします。
「お金を引き出しに来た人」 ＝ 「リクエスト」だと思って下さい。下図のようなイメージです。
僕はお金を引き出しに来た人ということですね。MVC構造でいうところの、リクエストということか。
永田さんは銀行でお金を引き出す際に、銀行のどこから入りますか？
・・・えーと、ドアですかね？
そうですね、自動ドアがありますよね。この自動ドアが先ほどの図でいうHTTPサーバにあたります。
自動ドア ＝ HTTPサーバか。
大きな銀行に入るとスタッフに声をかけられませんか？
受付のお姉さんとかですかね。
そうですね。この受付の案内係がルータと同じです。この案内係のお姉さんは何て声をかけてきますか？
・・・えーと、「ご用件は何ですか？」とかですかね。
そうですね、「ご用件は何ですか？」って聞かれますよね。そしたら永田さんは何て答えますか？
「お金を下ろしたいんですけど」と伝えます。
そしたら、「承知しました。5番窓口にどうぞ」と受付のお姉さんが窓口に案内しますよね。それで5番窓口に来た永田さんは何て言いますか？
「お金を下ろしたいです」と伝えます。
すると窓口係は、「承知しました。通帳と印鑑とこちらの用紙にご記入をお願いします」と言いますよね。
つまり、「永田さんの情報を下さい」と言うんですね。
なるほど。
永田さんは窓口係に情報を渡します。窓口係は、「少々お待ちください」と言って自分のポケットからお金を出すようなことはしないですよね？（笑）
しないです（笑）
なぜ、窓口係のポケットでお金を管理しないのか。それは、不正防止のためなんです。
| Ruby on Rails（MVC構造） | 銀行 |
|---|---|
| ①リクエスト | ①お金を下ろす人 |
| ②HTTPサーバ | ②自動ドア |
| ③ルータ | ③案内係 |
| ④コントローラ | ④窓口係 |
出金係はモデル（Model）
窓口係は、出金係に金庫からお金を下ろしてくるように指示するわけです。このお金を取ってくる出金係がモデル、金庫がデータベースにあたります。
なるほど。
その指示を受けた出金係が金庫からお金を取ってきて窓口係にお金を渡すわけです。お金を受け取った窓口係は、「お待たせしました」と永田さんにお金を渡しますね。
来た来た！
この時は現金だけ渡して、「はいどうぞ！」ってやりますかね？
うーん！？
現金以外に他に何か渡しませんか？
・・・明細とかですかね。
そうですそうです！通帳明細ですよね。お金と通帳明細を受け取った永田さんはそのまま窓口で突っ立ったままですかね？
お礼をして帰ります。
「ありがとうございました」と言って帰ることで用件が完了しますね。この帰ることがレスポンスにあたります。これらの銀行の仕組みがMVC構造と似ているんですよ。
僕もWebアプリケーションにアクセスしたりするんですけど、単純にボタンを押してるだけで、僕には見えていない裏側ではこういうことが行われているんですね。
そうですね！MVC構造とは、裏側の処理を銀行のような仕組みになっているわけなんですね。なぜこのような構造になっているのか。銀行から想像するとわかりやすいんですよ。誰でも大人になる過程で銀行に行きますよね？
行きますね。
私は「銀行に行ったことがない」なんて人を聞いたことがありません。なぜ銀行は、このような構造をしているんですかね？
うーん・・・。
銀行のスタッフが1人で、一度に大勢の人が来たらどうですか？
1人だったらパンクしそうです。
パンクしそうですよね！非効率ですよね。役割を分担すると自分がやるべきことに集中できるし、処理スピードも速いですよね。窓口っていっぱいあるじゃないですか。何でいっぱい窓口があるんですかね？
・・・えーと、役割分担するためですかね。
銀行って10番窓口ぐらいまでありますよね。どんな窓口がありますか？
投資とか。
後は？
口座を開設するとか。
他にはどうですか？
お金を借りるとか。
色々ありますよね。窓口が分かれているとシンプルですよね。
そうですね。
責任も明確になります。ミスがあった時に全スタッフに確認する必要がないですよね。
確かに。問題があった時は、その担当の人に聞けば良いですもんね！
窓口係から出金係に指示を出すときに、お金だけじゃないかもしれないですよね。現金以外に資産って何がありますかね？
・・・宝石とかですかね。
他にはどうですか？
他には不動産証券とか。
そうですね。不動産証券とか株とかですよね。それぞれ分かれていた方が専門特化できますよね。出金係が1人で「現金」「不動産証券」「株」を担当している場合は、何か1つを対応している際に他のお客さんに待ってもらわなければなりません。出金係は複数名いて専門特化した方が効率的ですよね。どこで何が起きたのかという責任の所在もわかりやすいですし。しかも金庫に入る人を限定するわけですからセキュリティが増します。だから、銀行は効率化するためにこのような構造になっているんです。
なるほど！
| Ruby on Rails（MVC構造） | 銀行 |
|---|---|
| ①リクエスト | ①お金を下ろす人 |
| ②HTTPサーバ | ②自動ドア |
| ③ルータ | ③案内係 |
| ④コントローラ | ④窓口係 |
| ⑤モデル | ⑤出納係 |
| ⑥データベース | ⑥金庫 |
通帳明細はビュー（View）
なぜ、通帳明細が必要なんですかね？
記録のためですか？
そうですね。その通帳明細の形式は、それぞれの人によって全然違いますか？それとも形式はある程度一緒ですか？
通帳明細の形式は似ているんじゃないですか。
例えば何ですか？
「名前」「金額」「日付」とかですかね。
そうですよね。共通部分があればテンプレート化ができますね。これはMVC構造でいうビューに相当するのですが、ビューも通帳明細と同様に共通部分がテンプレート化されています。
そうなんですね！
自動ドアがなかったら入れないですよね。案内係や窓口係が1人で全て対応していたら非効率ですよね。出納係を分けることによって金庫のセキュリティが保たれますよね。
確かに。
金庫の中で別々の箱に入ってる「現金」「不動産証券」「株」に対して出納係を1対1で対応させると、出納係の仕事が楽になるわけです。
金庫の中の別々の箱がわかるわけですもんね。
出納係は覚えやすいですし、何をすればいいかがわかりやすいんですよ。組織全体で役割を明確にすることで働きやすくなるわけです。銀行では、ミスが1円たりともあったりしてはいけないんです。仮に永田支店長が渋谷本店に赴任してきて、「全ての役割を1人で全部やって下さい」と言われたらどうですか？
もうパンクですよ。
死んじゃいますよね。でも、先ほどの銀行の仕組みがあれば同時並行で処理ができますね。
確かにそうですね。
これが最適解ですよね。仮に銀行は1日1000人ぐらい来店するとして、インターネットの世界は1日どれぐらいアクセスがあると思いますか？例えば、Yahooのトップページとか。
何百万とか来そうですね。
そうですね、大量のアクセスがありますよね。効率化しないと話にならないんです。役割を分担して同時並行する。ちゃんと連携して常に大量のアクセスを捌くわけです。そういう時にこれまでに説明した構造になっていると良いですよね。
インターネットのシステムの場合も、パンクしないように役割を分担して同時並行できるようにしています。どのインターネットのシステムも基本的な仕組みは同じです。毎回ゼロから作ったら大変じゃないですか。それで、データを引き出す役割を持つモデルがあり、画面を表示するビューがあり、それを中間管理で行うコントローラがある。その三つ巴の仕組みをテンプレート化しているのがMVC構造なんですね。
なるほど！インターネットのアクセスに対する処理をするために、最適であろうものがセットになっているのがMVC構造なんですね。
銀行でいえば、役割が明確になり、同時に多くのお客さんの対応ができます。不正もなくなり効率的になるわけです。これがRuby on Railsの場合は、どの部分にどのようなプログラムが書いてあるのかが一目瞭然になります。それを管理している人間から役割が明確になっているので書きやすいし、管理しやすいんです。だから、「MVC構造にしましょう」という話に繋がります。以上がRuby on RailsのMVC構造を銀行に例えた話です。
なるほど、分かりやすかったです！ありがとうございました。
| Ruby on Rails（MVC構造） | 銀行 |
|---|---|
| ①リクエスト | ①お金を下ろす人 |
| ②HTTPサーバ | ②自動ドア |
| ③ルータ | ③案内係 |
| ④コントローラ | ④窓口係 |
| ⑤モデル | ⑤出納係 |
| ⑥データベース | ⑥金庫 |
| ⑦ビュー | ⑦通帳明細 |
| ⑧レスポンス | ⑧帰る |
【まとめ】
1. 窓口係はコントローラ（Controller）。コントローラはモデルとビューを管理する役割を担っている。
2. 出金係はモデル（Model）。データを引き出す役割を担っている。
3. 通帳明細はビュー（View）。画面に表示する役割を担っている。
MVC構造と銀行の流れをおさらい。
| Ruby on Rails（MVC構造） | 銀行 |
|---|---|
| ①リクエスト | ①あなたが現金を下ろしに銀行へ到着する |
| ②HTTPサーバ | ②入り口の自動ドアから銀行の中に入る |
| ③ルータ | ③案内係があなたの用件を聞き、窓口へ案内する |
| ④コントローラ | ④窓口係があなたの用件を聞く |
| ⑤モデル | ⑤窓口係が出金係に現金を下ろすように指示を出す |
| ⑥データベース | ⑥出金係が金庫から現金を取ってくる |
| ⑦ビュー | ⑦出金係が現金を窓口係に渡し、窓口係があなたに現金と通帳明細を渡す |
| ⑧レスポンス | ⑧あなたは用件が完了し帰る |
まずは頭の中で2つの上図をイメージして、MVC構造の流れを銀行に例えて考えてみましょう。一連の流れを理解できれば、細かい部分の理解が進みます。
■プログラミング初学者を対象としたディープロの無料教材「PREコース」はこちら
