- WEBのMVCはとっ散らかっているので解説
- なんでこんな、とっ散らかったのか説明するため、経緯を説明
- 結局どうすれば、メンテナンス性がいいのか
- わけのわからない考え方
- Railsが、ActiveRecordだけをModelと定義した理由
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クラスなど )に放り込めばいいじゃないの?というつっこみで、終了した。
大本が、そもそも間違っているので、適当な対処療法では、かえってこんがらがるだけというパターン。
対処療法的な考え方は、他にもありそう。
わけのわからないアイデアは、対処療法的なものかもしれないので、要注意。
Railsが、ActiveRecordだけをModelと定義した理由
Rails以前は、こんな問題もあった。
DBテーブルの処理がどこに書かれているのかわからない状態。
こうなってくると、DBテーブルの変更をするときに、アプリケーション全体を見ないといけなくなる場合がある。
その状態を、できるだけ作らせないために、DBテーブルごとの処理を一か所にまとめる目的で、ActiveRecordだけをModelと定義したのかもしれない。
この考え方自体は、とても有意義なんだけど、問題は、アプリケーションには、どのDBテーブルに属しているとも言えない処理が含まれていること。
そのため、これまで解説したような問題になってきた。
つまり、Serviceクラスを使うことで、下手すると、DBテーブルの処理がどこに書かれているのかわからないという問題が、再度発生してしまう可能性がある。
そうしないために、ActiveRecordに配置するべき処理は、ActiveRecordに配置するようにすればいい。
役割分担を、徹底することで、この問題は回避できると思う。
画像提供元: Pixabay
#Web#MVChttps://t.co/q6B4qFWShw
— zakkiのブログ (@zakkinoblog) 2021年9月13日