MVCの考えをWebで使う必要があるんでしょうか？

今のWebDBアプリは1ページを表示する間にSQLの数だけコントローラーと

モデルを何十往復もする書き方が推奨されて

単にツギハギだらけで不便だと思います。

少なくともこれが議論にあがるということは View の分離はかまわないと考えていいのかな？

少なくとも上記状態は単にコーディングがつたないだけで　MVC　が有用かどうかには関係ないと思われる。

今時のフレームワークなら大体 OR マッピングとセットになっているので、OR マッピングを

Model と勘違いしているケースは多い。

OR　マッピングは文字通りデータをプログラム上に追加しただけで本来モデルとして想定される

ビジネスロジックが含まれない。

ビジネスロジックを記述する層（仮にサービス層とでも呼ぼう）までを含めてモデルとしなければ

MVC　モデルを適用しているといいがたく、それをもってMVCを語るのは不適当と思われる。

はてな

ご存知かと思うが MVC （一般にWeb 用にタイプ２と呼ばれるもの）はビジネスロジックを表す

Model、、画面表示を表す View 、その間を制御する Controller で構成される。

Model は上記のとおり OR マッピング等とそれを操るサービス層、 View は主に HTML を中心としたテンプレートエンジンを用いることにはさほど違和感は無いように思う。

あとはその間を結ぶものを　Controller　と呼んでいるだけだ。

実際にきちんとその役割分担をはっきりさせたコードであれば読みやすいし意図も明確になる。

十分なメリットは感じている。

もちろん MVC が最善かどうか？の議論は以前からあるし、最近でもいろいろな議論が起こっているようだ。

ただ、まずは MVC をきちんと適用できているかを見直してみる事を薦める。

MVC　が最善というつもりもないが、その論議をする以前の問題であることが非常に多いように思う。

MVCに限らず大抵のパターンは、その本来の意義に基づいて使用して初めて意味を成す。

形だけまねたものを作っても効果がないどころか無駄ですらある。

ちなみに、これは私見だが Web に関してのMVCモデルの利点はいわゆる再利用性といったものはあまり無い。

役割を適切に分担することでコードの可読性とメンテナンス性の向上が主なメリットだと思う。

これは作成時よりもメンテナンス時のほうがより効果を感じることができる。

それを上回るメリットがあるならば、どのようなパターンでもかまわないが自分は寡黙にしてそれを知らない。

「今のところ」ベストではないかもしれないがベターな選択と感じている。

>今のWebDBアプリは1ページを表示する間にSQLの数だけコントローラーと

>モデルを何十往復もする書き方が推奨されて

これは明らかな間違いです。

こんなことをしていたらレスポンスは悪くなるし、

セキュリティ上の危険も増します。

下記サイトに書かれていることが、MVCを導入する一番の大きな理由だと思います。

サーバーサイドで、MVCフレームワークが重要になった要因として、WEBアプリケーションの規模に応じて、とてつもなく画面遷移が多くなることがあげられます。画面遷移の制御をコントローラーに集約しないと、手のつけようがなくなってくる。

http://www.goodpic.com/mt/archives2/2005/09/ajaxmvc.html