MVCの典型的な相関図

Model-View-Controller (MVC、モデル・ビュー・コントローラ) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である。

MVCはソフトウェアを処理/Model・表示/View・入力伝達/Controllerの3要素に分割し、ソフトウェア内部データをユーザーが直接参照・編集する情報から分離する。プレゼンテーション（View・Controller）とドメイン（Model）を分離しまたユーザー入力（Controller）と表示（View）も分離することでソフトウェアの保守性・開発生産性を向上させる。

MVCの歴史

• 1979年: パロアルト研究所にてトリグヴェ・リーンスカウクが考案^[1][2]。長い間、Smalltalk-80の実装のみが公開され、MVCに関する公開情報はなかった
• 1988年: 最初の論文「A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80」^[3]が公開^[4]
• 1994年: 書籍「Design Patterns:Elements of Reusable Object-Oriented Software」^[5]内で取り上げられる
• 1999年: MVCのサーバサイド実装としてJavaServer Pages Model 2が発表^[6]

元来Smalltalkにおけるウィンドウプログラム開発のための設計指針として生まれたが、構造が複雑となりがちなグラフィカルユーザインターフェース (GUI) をもつソフトウェアにおける有用性から他方面へ広がった。

その後、Smalltalk-80から派生したSqueakでは、Selfから移植されたGUIツールキットMorphicが主に使われるようになった^[要出典]。Morphicではビューとコントローラを分離しておらず、その後の多くのGUIツールキット^[どれ?]でもビューとコントローラは完全には分離されていない^[要出典]。これはビューとコントローラはお互いに強く依存しており、分離する利点よりも欠点の方が上回ったためである^{[独自研究?]}。

MVCの構造

MVCでは、プログラムを3つの要素、Model（モデル）、View（ビュー）、Controller（コントローラ）に分割する。

モデル

そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。また、データの変更をビューに通知するのもモデルの責任である（モデルの変更を通知するのにObserver パターンが用いられることもある）。

ビュー

モデルのデータを取り出してユーザが見るのに適した形で表示する要素である。すなわち、UIへの出力を担当する。例えば、ウェブアプリケーションではHTML文書を生成して動的にデータを表示するためのコードなどにあたる。GUIにおいては通常、階層構造を成す。

コントローラ

ユーザからの入力（通常イベントとして通知される）をモデルへのメッセージへと変換してモデルに伝える要素である。すなわち、UIからの入力を担当する。モデルに変更を引き起こす場合もあるが、直接に描画を行ったり、モデルの内部データを直接操作したりはしない。

なお、UIにおける入力と出力は本質的には不可分なものであり、したがってビューとコントローラはいつでも分離できるとは限らない。このようなM-VCとなるような構造をDocument-Viewと呼ぶ^[7]。

MVCのシナリオ

MVCの実装はさまざまであるが、制御フローは一般的に次のようになる^[3]。

1. コントローラが入力機器（マウスやキーボードなど。Smalltalk-80ではInputSensorで表わされる）を監視する。
2. ユーザが入力機器に入力を与える。
3. コントローラがユーザのアクションに応じてモデルのメソッドを呼ぶ。その結果モデルのデータが書き換えられる場合もある。
4. モデルが変更された場合、自身が変更された旨をビューなどのオブザーバに対して通知する。
5. ビューはモデルから関連するデータを取得し、出力を更新する。典型的には画面に図形を描画する。

このシナリオでビューやコントローラをそれぞれ1つのオブジェクトとして単純化して説明しているが、実際にはビューは階層構造になっていて、各ビューごとに対応するコントローラが存在する。そのためユーザからの入力を処理すべきコントローラを決定する作業が必要となる。例えばSmalltalk-80ではマウスカーソルを含むビューに対応するコントローラが入力を処理するのが原則であり、次のようなステップで入力を処理すべきコントローラを決定する。

1. コントローラはビューに対し、入力を処理すべきコントローラを問い合わせる（ビューの位置や階層構造を知っているのはビューなので）。
2. ビューはコントローラに現在のマウスカーソルの位置を問い合わせる（入力機器の状態を知っているのはコントローラなので）。
3. ビューはマウスカーソルを含むビューを探す。
4. そのビューに対応するコントローラを、入力を処理すべきコントローラとする。

MVCとデザインパターン

MVCは、デザインパターンの1種と扱われる場合もあるが（MVCパターンと呼称される）、MVC自体が他の小さなデザインパターン(Observer パターン・Command パターン・Factory Method パターン・Facade パターンなど)を利用して実装されることが多いところからすると、デザインパターンというより、さらに粒度の大きい1種のソフトウェアアーキテクチャという方が適当であろう^[7][8]。

各モジュールが比較的はっきりと分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミングなどにも適している。

脚注

1. ^ MVC XEROX PARC 1978-79
2. ^ The Model-View-Controller (MVC) Its Past and Present
3. ^ ^{a b} A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80
4. ^ Model View Controller History
5. ^ The "Gang of Four": Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2 
6. ^ Understanding JavaServer Pages Model 2 architecture
7. ^ ^{a b} Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal (1996). Pattern-Oriented Software Architecture. John Wiley and Sons. ISBN 0-471-95869-7 
8. ^ Model View Controller As An Aggregate Design Pattern

関連項目

• イベント駆動型プログラミング
• 多層アーキテクチャ
• JFace、Google Web Toolkit、Spring MVC フレームワーク
• モデルを分離するアーキテクチャ
  • Model View ViewModel
  • Model View Presenter