Ｗｉｋｉによると、
Model View Controller（モデル・ビュー・コントローラ; MVC）は、コンピュータ内部のデータをユーザに提示し、それに対してユーザが何らかの指示を出すタイプの、独自のユーザーインタフェースをもつアプリケーションソフトウェアを、以下に述べるようなmodel・view・controllerの3つの部分に分割して設計・実装するという技法、又はそのような構造をいう。
となっている。
やってみれば判るが、model・view・controllerは互いに従属し、遷移あるいは結合が増えるたびに従属関係は複雑怪奇になっていく。
早い話が【伝言ゲーム】なのである。
ツリー状に枝葉が伸びていく分には余り支障は無いが、後になって、一本串を刺す様に伝言の内容（名前は１０文字から２０文字に変更になりました。等）が変ると一大事である。
このため、現在のＭＶＣは、伝言の内容をＦＯＲＭと称して仕様書上の隠蔽化を図っているが、ＰＨＰやＪＳＰなど画面にバッチリを書き込まなければいけない部分は全部書き換えである。
※もしくはヒデュン（非表示）エリアにＦＯＲＭを全部転記するかセッションで保持し、画面情報を一づつ吟味して転記するしかない。どっちみち面倒である。
つまり、後の保守は他人に任せてのが最適であり、アプリケーションのＵＩ設計をＭＶＣで行うということは、『開発完了』までしか念頭に無いと思われる。
何のことは無い、前世期のホスト・ターミナルからある『電文』という業界用語をMVCと云ってるだけなのだ。唯一違う点は、【送信ボタン】が『キーボード』から『ディスプレイ』の中に移動しただけである。
更にWikiの文面を続けると、
各モジュールが比較的截然と分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミングなどにも適している。
となっている。
僕とは反対の感想をお持ちの方が書かれたらしい。だが、どちらもＭＶＣの一側面であり、
使い方次第では、
本当に【プログラムの見通しがよくなる】が、普通ただの【伝言ゲーム】に成り下がるしろものである。
要は設計次第で、各モジュールが比較的截然と分かれとなっているか、なっている様に見せかけているかである。
この辺は仕様書では綺麗に誤魔化しているので、ソースを読んでみてみるまで全く判らないのである。
という訳で、本当は『自動プログラミング』にこそ適したＵＩ設計手法なのであろうが、
『自動プログラミング』でまともなモノはまだ見たこともないので、当分無理そうである。
というのも、web.xmlにしろ、validateにしろ、一から作成するなんてことはまず考えに入っていないとしか思えないんだがら・・・（笑
もっとも、httpd.confやsendmailやphp.iniも、同類ですけどね・・・。
そんなシロモノばかりを集めて出来上がったのが今のインターネットだから・・・。
実際は、コンピュータより手間や保守の方が高く付くのは仕方が無いし、Linuxをインストしたら、ぶっ飛んだりしても仕方がないんだろうね。
ネットワークだけに仕様なんか無視して増設しまくるから、物凄い蛸足配線になっていても別に不思議ではないと思う。（大笑