MVCのCって何ぞや
いろんなところで聞くMVC
正直、railsはmvcで構成されているからみたいなと言われても、なぜそうなっているのか分からない。多少知っているのは、責務の分配を行うことで保守しやすくなるくらい？
ということで、調べてみた。
そもそも、model、view、controllerの概念を説明できるか？
本当に基本的なことだが、それぞれを言語化してみる。
-
Model… ビジネスロジックを担当する部分。DBとやり取りを行ったり、データの登録、更新、削除を行う。
-
Controller… Modelにデータ処理の指示を出したり、viewに画面表示の指示を出す。
-
View… 表示や入出力などのユーザーインターフェースを担当する部分。
そんなこと言われても、分かんねえよという方向けに
具体例で見ていく。
- View ユーザーが商品を選択して購入ボタンをクリックする
- Controller ユーザーの購入情報をViewから受け取り、Modelに購入情報の登録を指示する
- Model ユーザーの購入情報をDBに登録し、登録処理の結果をContorllerに返す
- Controller Modelから登録処理の結果を受け取り、購入完了画面をViewに送る
- View 購入完了画面を表示する
この流れは、
VIew -> controller -> Model -> Controller -> View
となっている。
ここで疑問に思ったのだが、controllerいる？問題である。
もちろん、controllerにバリデーションなどを持たせるなどもわかるのだが、別にそれってviewに書けば良くね？とか余計なことを思ってしまう。
結局、Viewからmodelに処理を渡しているなら、ただ経由しているだけでMVでいいんじゃないかと思ってしまった。（というか、今まで何も考えずにそうやって設計していた。)
ここで一周回ってひとまとめにしてみる。
ひとまとめにしたらどうなるのだろう。
まあ想像するのも地獄である。サイトの見た目なんかはしょっちゅう変わるし、共同開発などしようものなら、コンフリクトの嵐である。
まあこれはいい、問題はMVである。
なんでMVじゃダメなの？
これは、https://qiita.com/tshinsay/items/5b1724baf32b8b5113c2
こちらの記事にわかりやすく書いてある。
View側のボタンなどの分岐処理をmodelかviewどちらに書くのかということについて触れているが、どちらに書いても地獄である。
これをcontrollerでやってしまおうというのが、MVCのCの部分である。
つまり？
ユーザーの操作に基づいた処理をcontrollerで書くべきである。
ここで注意！
じゃあcontrollerにボタンの分岐処理のロジックを書くことになるじゃないかと思うかもしれないが、それは違う。
あくまで、controllerが行うのは、ユーザーが行った操作に基づく処理で、
その処理の中身は、全てmodelに書く。
結局コントローラーが何をするところ？
Modelの持っている加工メソッドを操作する！！！！！
あとがき
それでは、現在進行形間違ったMVCで開発している個人開発をリファクタしてきます。
お疲れ様でした。
参考文献
Discussion