zakkiのブログ

IT関連などの雑記のブログです

記事を一覧で表示する

WEBのMVCはとっ散らかっているので解説

IT

f:id:zakkinoblog:20210810121150p:plain



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クローン期


PHPでRailsのクローンがたくさんできていった。


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