MVCの典型的な相関図
Model-View-Controller (MVC、モデル・ビュー・コントローラ) はUI を持つソフトウェア に適用されるソフトウェアアーキテクチャ の一種である。
MVCはソフトウェアを処理/Model・表示/View・入力伝達/Controllerの3要素に分割し、ソフトウェア内部データをユーザーが直接参照・編集する情報から分離する。プレゼンテーション(View・Controller)とドメイン(Model)を分離 しまたユーザー入力(Controller)と表示(View)も分離することでソフトウェアの保守性・開発生産性を向上させる。
MVCの歴史
元来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] 。
コントローラが入力機器 (マウス やキーボード など。Smalltalk-80ではInputSensorで表わされる)を監視する。
ユーザが入力機器に入力を与える。
コントローラがユーザのアクションに応じてモデルのメソッドを呼ぶ。その結果モデルのデータが書き換えられる場合もある。
モデルが変更された場合、自身が変更された旨をビューなどのオブザーバに対して通知する。
ビューはモデルから関連するデータを取得し、出力を更新する。典型的には画面に図形を描画する。
このシナリオでビューやコントローラをそれぞれ1つのオブジェクトとして単純化して説明しているが、実際にはビューは階層構造になっていて、各ビューごとに対応するコントローラが存在する。そのためユーザからの入力を処理すべきコントローラを決定する作業が必要となる。例えばSmalltalk-80ではマウスカーソルを含むビューに対応するコントローラが入力を処理するのが原則であり、次のようなステップで入力を処理すべきコントローラを決定する。
コントローラはビューに対し、入力を処理すべきコントローラを問い合わせる(ビューの位置や階層構造を知っているのはビューなので)。
ビューはコントローラに現在のマウスカーソルの位置を問い合わせる(入力機器の状態を知っているのはコントローラなので)。
ビューはマウスカーソルを含むビューを探す。
そのビューに対応するコントローラを、入力を処理すべきコントローラとする。
MVCとデザインパターン
MVCは、デザインパターン の1種と扱われる場合もあるが(MVCパターンと呼称される)、MVC自体が他の小さなデザインパターン(Observer パターン ・Command パターン ・Factory Method パターン ・Facade パターン など)を利用して実装されることが多いところからすると、デザインパターンというより、さらに粒度の大きい1種のソフトウェアアーキテクチャ という方が適当であろう[ 7] [ 8] 。
各モジュールが比較的はっきりと分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミング などにも適している。
脚注
^ MVC XEROX PARC 1978-79
^ The Model-View-Controller (MVC) Its Past and Present
^ a b A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80
^ Model View Controller History
^ 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
^ Understanding JavaServer Pages Model 2 architecture
^ 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
^ Model View Controller As An Aggregate Design Pattern
関連項目
GoFによる23種のパターン
生成に関するパターン 構造に関するパターン 振る舞いに関するパターン
並行性に関するパターン アーキテクチャに関するパターン その他のパターン 関連する人々 関連項目