皆様、こんにちは。どんぶラッコです。
MVCって、皆さん理解できますか？
私は最初は全く意味がわかりませんでした…。
なんとなく言ってることはわかるのですが、なぜそんなことをしなきゃいけないのか、そしてモデル、コントローラ、ビューそれぞれの分け方の判断基準が全然わかりませんでした。
しかも、調べるといろんな図が出てくるじゃないですか。
でも、ポイントは結局「それぞれが何をしているのか」ということを抑えることです。
ということで、今回も例え話で理解しちゃいましょう！
「塗り絵」の例え話で。
塗り絵で理解するMVCモデル
登場人物はこの3つです。
一目瞭然ですね！
- 色鉛筆をくれるおばあちゃん（！）
- 女の子
- 塗り絵
です！
まず重要なのは、指示を出すことが出来るのは女の子だけ、ということです。
おばあちゃんは女の子のしたがって色鉛筆を準備してくれます。
そして、女の子の目的は綺麗な塗り絵をお母さんに見せることです。
さて、女の子はどうやって塗り絵を完成させるのでしょうか。
コントローラ ⇄ モデル
先ほども述べたように、女の子は考えることができます。なので、塗り絵をみて「赤色で塗ったらいいなあ」ということを計画します。
そして、おばあちゃんに色鉛筆を要求します。
それに対しておばあちゃんは色鉛筆を渡してくれます。
コントローラ ⇄ ビュー
そして、女の子はおばあちゃんからもらった赤鉛筆を使って、塗り絵をします。
そして最終的に塗り絵はお母さんがみることになるのです。
MVCに直してみよう！
実は、たったこれだけでMVCの理解は完璧です！それぞれをちゃんとした言葉で当てはめてみましょう。
お母さんはユーザです。
そして、コントローラに「塗り絵をみたい」を要求します(HTTP リクエスト)。
それを受けた女の子(コントローラ)が必要に応じて色鉛筆（データ）をおばあちゃんから受け取ります。
最後に、その色鉛筆を使ってViewのフレームワーク(塗り絵)を完成させて、お母さんに返してあげるわけです。
こうやって例え話に落とし込むと理解しやすいですね！
このように役割を分けるメリットは、問題発見のしやすさです。
色鉛筆、つまりデータが渡されなかったら、モデルに問題があります。見た目が変だったら、塗り絵の元絵、ビューに問題があります。そして、指示が変だったらコントローラのせいです。
こんな風に、起こった問題に対して、どこを見ればいいのか、とてもわかりやすくなるんですね！
こうやって例え話にすることで、理解が深まるということもあります。
ぜひ皆さんもわからないことがあったら、「身近な例」に置き換えて考えてみてください！
[…] […]
[…] […]