Model-View-Controller (MVC、モデル・ビュー・コントローラ) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である。
MVCはソフトウェアを処理/Model・表示/View・入力伝達/Controllerの3要素に分割し、ソフトウェア内部データをユーザーが直接参照・編集する情報から分離する。プレゼンテーション(View・Controller)とドメイン(Model)を分離しまたユーザー入力(Controller)と表示(View)も分離することでソフトウェアの保守性・開発生産性を向上させる。
元来Smalltalkにおけるウィンドウプログラム開発のための設計指針として生まれたが、構造が複雑となりがちなグラフィカルユーザインターフェース (GUI) をもつソフトウェアにおける有用性から他方面へ広がった。
その後、Smalltalk-80から派生したSqueakでは、Selfから移植されたGUIツールキットMorphicが主に使われるようになった[要出典]。Morphicではビューとコントローラを分離しておらず、その後の多くのGUIツールキット[どれ?]でもビューとコントローラは完全には分離されていない[要出典]。これはビューとコントローラはお互いに強く依存しており、分離する利点よりも欠点の方が上回ったためである[独自研究?]。
MVCでは、プログラムを3つの要素、Model(モデル)、View(ビュー)、Controller(コントローラ)に分割する。
なお、UIにおける入力と出力は本質的には不可分なものであり、したがってビューとコントローラはいつでも分離できるとは限らない。このようなM-VCとなるような構造をDocument-Viewと呼ぶ[7]。
MVCの実装はさまざまであるが、制御フローは一般的に次のようになる[3]。
このシナリオでビューやコントローラをそれぞれ1つのオブジェクトとして単純化して説明しているが、実際にはビューは階層構造になっていて、各ビューごとに対応するコントローラが存在する。そのためユーザからの入力を処理すべきコントローラを決定する作業が必要となる。例えばSmalltalk-80ではマウスカーソルを含むビューに対応するコントローラが入力を処理するのが原則であり、次のようなステップで入力を処理すべきコントローラを決定する。
MVCは、デザインパターンの1種と扱われる場合もあるが(MVCパターンと呼称される)、MVC自体が他の小さなデザインパターン(Observer パターン・Command パターン・Factory Method パターン・Facade パターンなど)を利用して実装されることが多いところからすると、デザインパターンというより、さらに粒度の大きい1種のソフトウェアアーキテクチャという方が適当であろう[7][8]。
各モジュールが比較的はっきりと分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミングなどにも適している。