WEBのMVCはとっ散らかっているので解説
初心者は何が何だかわからないと思うので、全部解説。
とにかく、とっ散らかっていて、忖度の嵐によって、簡単な結論に、延々と到達できていないという、バカバカしいことがずっと続いている。
djangoしか知らない人向けの注意事項
djangoでは、controller が view で、view が template になるので注意。
なんでこんな、とっ散らかったのか説明するため、経緯を説明
Web黎明期
WebでPHPが広まっていったころ。
MVCという考え方自体は、以前からあったけど、IT業界というのは、新しい技術ができた時に、元からあった考え方を捨ててしまうらしい。
そのため、MVCを無視した、ぐちゃぐちゃな実装がされるようになった。
MVC全部が混ざった状態。
当然、悲惨な結果になった。
フレームワーク模索期
いろいろなフレームワークが模索されていったけど、あまり決め手がなかった。
PHPの場合は、自前のフレームワークとSmartyでなんとかお茶を濁す場合も多い。
RubyOnRails期
2006年ころRoRが出てきて、一気に広まった。
ついでに、Rubyも広まった。
たしか、初期のころはroute処理がなかったと思う。
そこに、routeやresouceなどによるRestFulな考えが広まっていって、大体今と同じ形になっている。
最初のうちにほぼほぼ完成されているので、昔と、あんまり変わっていない。
RubyOnRailsクローン期
Railsほどなんでもできるわけじゃないけど、どれも、そこそこ使える。
性能はそこそこだけど、その分、融通が利く。
あれっ？フレームワークを使っているのになんか変だぞ期
Railsは、DBテーブル管理をするクラスの派生クラス（ActiveRecord）だけを、Modelと定義している。
つまり、それ以外のアプリケーションで必要となるクラスの置き場所がない。
この場合、対処するのは大まかに2パターン。
- Model（ActiveRecord）とControllerに無理やり押し込む。
- Servicesとか、Componentsとか、適当にクラスを作り、そこに配置する。
普通は、後者を選ぶと思うかもしれないけど、前者が結構多い。
前者の場合は、フレームワークを使っているのに、メンテナンス性が悪くなっていった。
Modelの定義を変えたほうがいいのではないか期
ActiveRecordだけを、モデルとして考えるのはやめよう、という考え方ができてくる。
ただ、Railsのロイヤリティが高いため、それに反発する人も出てくる。
とりあえず、誤魔化し、誤魔化しやっていこう期
現在は、この状態。
例えば、Laravelでは、Modelsフォルダがない。
つまり、こんなやり方 ( Model/Eloquents ) でやるのが本来なんじゃないという、つっこみのようなもの。
ただ、Railsにロイヤリティが高い人も多いので、あとは勝手にどうぞというスタンス。
結局どうすれば、メンテナンス性がいいのか
本来のMVCではこれが正解。
controlers/
views/
model/
activerecords/
services/
forms/
・
・
上記が、本来のMVCという意味では正解。
なぜなら、本来のMVCでは、VC以外は全部Modelだから。
ただし、
現実的には、これが主流。
controlers/ views/ models/ services/ forms/ ・ ・
Laravelでは、models を eloquents にすることもこっそり推奨している。
おまけ
WebのMVCがとっ散らかった結果、
MOVEという、わけのわからない考え方も出てきた。
上記の経緯により、controllerにすべてを記述する人が出てきたため、
コントローラーを O E に分けて管理する的な奴だったと思う。
O E が何なのかは忘れた。
ただこれは、Controllerに書いている部分を、本来の意味でのModel（ Serviceクラスなど ）に放り込めばいいじゃないの？というつっこみで、終了した。
大本が、そもそも間違っているので、適当な対処療法では、かえってこんがらがるだけというパターン。
対処療法的な考え方は、他にもありそう。
わけのわからないアイデアは、対処療法的なものかもしれないので、要注意。
画像提供元: Pixabay
#Web#MVChttps://t.co/q6B4qFWShw
— zakkiのブログ (@zakkinoblog) 2021年9月13日
記事を探す時は、上記のカテゴリー一覧や、まとめページから探すと、探しやすいです。