歴史を日米Wikipediaなどで調べると、1970-1980年頃のCUI全盛期に
アランケイがDynabook/smalltalkの実験でGUI(ウィンドウ)やマウスを開発しつつ
「入り口と出口は取替可能に」と開発のコツを言った程度のように思います。
なるほどOS基本アプリを作るならそう思うでしょう。
UNIXで入力をキーボードやファイル、出力を画面やプリンタやファイルに
切り替える動作を意識した言葉でしょう。
どういう解釈でWebで使われてるんでしょう?
今のWebDBアプリは1ページを表示する間にSQLの数だけコントローラーと
モデルを何十往復もする書き方が推奨されて
単にツギハギだらけで不便だと思います。
周りの人にきいても「それが便利だ」「ルールだ」としか言いません。
具体的な理由や経緯を答えてくれません。皆理由もなしに納得しているんでしょうか?
もしかして言葉が一人歩きしてませんか?
私はベタ書きのWeb時代から入っており、
OOPやフレームワークも理解実装ともに支障ないですが、この点は疑問です。
今のWebDBアプリは1ページを表示する間にSQLの数だけコントローラーと
モデルを何十往復もする書き方が推奨されて
単にツギハギだらけで不便だと思います。
少なくともこれが議論にあがるということは View の分離はかまわないと考えていいのかな?
少なくとも上記状態は単にコーディングがつたないだけで MVC が有用かどうかには関係ないと思われる。
今時のフレームワークなら大体 OR マッピングとセットになっているので、OR マッピングを
Model と勘違いしているケースは多い。
OR マッピングは文字通りデータをプログラム上に追加しただけで本来モデルとして想定される
ビジネスロジックが含まれない。
ビジネスロジックを記述する層(仮にサービス層とでも呼ぼう)までを含めてモデルとしなければ
MVC モデルを適用しているといいがたく、それをもってMVCを語るのは不適当と思われる。
ご存知かと思うが MVC (一般にWeb 用にタイプ2と呼ばれるもの)はビジネスロジックを表す
Model、、画面表示を表す View 、その間を制御する Controller で構成される。
Model は上記のとおり OR マッピング等とそれを操るサービス層、 View は主に HTML を中心としたテンプレートエンジンを用いることにはさほど違和感は無いように思う。
あとはその間を結ぶものを Controller と呼んでいるだけだ。
実際にきちんとその役割分担をはっきりさせたコードであれば読みやすいし意図も明確になる。
十分なメリットは感じている。
もちろん MVC が最善かどうか?の議論は以前からあるし、最近でもいろいろな議論が起こっているようだ。
ただ、まずは MVC をきちんと適用できているかを見直してみる事を薦める。
MVC が最善というつもりもないが、その論議をする以前の問題であることが非常に多いように思う。
MVCに限らず大抵のパターンは、その本来の意義に基づいて使用して初めて意味を成す。
形だけまねたものを作っても効果がないどころか無駄ですらある。
ちなみに、これは私見だが Web に関してのMVCモデルの利点はいわゆる再利用性といったものはあまり無い。
役割を適切に分担することでコードの可読性とメンテナンス性の向上が主なメリットだと思う。
これは作成時よりもメンテナンス時のほうがより効果を感じることができる。
それを上回るメリットがあるならば、どのようなパターンでもかまわないが自分は寡黙にしてそれを知らない。
「今のところ」ベストではないかもしれないがベターな選択と感じている。
>今のWebDBアプリは1ページを表示する間にSQLの数だけコントローラーと
>モデルを何十往復もする書き方が推奨されて
これは明らかな間違いです。
こんなことをしていたらレスポンスは悪くなるし、
セキュリティ上の危険も増します。
下記サイトに書かれていることが、MVCを導入する一番の大きな理由だと思います。
サーバーサイドで、MVCフレームワークが重要になった要因として、WEBアプリケーションの規模に応じて、とてつもなく画面遷移が多くなることがあげられます。画面遷移の制御をコントローラーに集約しないと、手のつけようがなくなってくる。
確かに超がつくほど大規模なら、私も分離しようと考えると思います。
おっしゃるとおりで、今のプロジェクト状況は「MVCもどき」で多くの処理がコントローラーにあります(笑)
ひとかたまりの処理はmodelにまとめコントローラーは道先案内というのは理論として知っているのですが、実装で見るのはSQLを切り出したようなモデルばかりなんで、なんだこりゃと思って質問した次第です。