Model-View-Controllerアーキテクチャパターン（MVC）は，対話型アプリケーションを3つのコンポーネントに分割する．モデルコンポーネントは，アプリケーションの中核機能とデータを含むコンポーネントである．ビューコンポーネントは，情報をユーザに表示するコンポーネントである．そして，コントローラは，ユーザの入力を取り扱うコンポーネントである．ユーザインタフェースを実現するのは，ビューコンポーネントとコントローラコンポーネントである．更新伝播のメカニズムによって，ユーザインターフェースとそのモデルとの一貫性を保証することできる．
前提
人間とコンピュータのインターフェースに柔軟性をもたせた対話型アプリケーションをつくる．
課題
ユーザインターフェースは要求仕様の変更が多い． たとえばアプリの機能を拡張しようとすると，その呼出しメニューを変更しなければならない．
以下のフォースがこの課題に対する解決策にヒントを与える．
- 同一情報を別々のウィンドウに異なる形式で表示する必要がある
- データに対して行われた操作が，直ちにアプリケーションの表示と動作に反映される必要がある
- ユーザインターフェースの変更を容易に行える．
- 表示のためのコードがアプリの中核となるコードとの結合性が低い
解決策
対話型アプリを3つの領域に分ける．
ビューとコントローラをモデルから分離することによって，同一モデルに対して複数ビューを持たせられる．
静的側面
モデル
アプリの機能中核となる部分を含む． データと機能をカプセル化する．
- アプリ処理を行う関数を公開する．
- コントローラがこの関数にアクセスする．
- モデルはデータにアクセスする関数も提供する
- ビューがこの関数を使って表示するデータを取得する
更新伝播メカニズム
モデルに依存するコンポーネントの登録を管理する 全てのビュートコントローラが変更通知依頼を行う． モデルの状態変化が変更伝播メカニズムの引き金となる．
ビュー
ユーザに情報を提供する．
コントローラ
イベントなどのユーザ入力を受け取る．
MVCのオブジェクト指向実装では，ViewクラスとControllerクラスは同一親クラスを持ち，その親クラスに更新用インターフェースが用意される． そしてModelがその更新用インターフェースを呼び出す．
動的側面
シナリオ1
モデルを変化させるユーザ入力が更新伝播メカニズムをどのように駆動するか示したもの
- コントローラはイベントハンドリング手続きでユーザ入力を受取，そのイベントを解釈し，モデルのサービス手続きを活性化する
- モデルは，リクエストされたサービスを実行する．その結果モデルの内部データが変わる．
- モデルは，更新伝播メカニズムに登録された全ビューとコントローラに更新通知を送る．
- 各ビューがモデルに更新データをリクエストし，自らを再表示する．
- 各コントローラがデータを取得する．
シナリオ2
初期化のためのコードは，モデル・ビュー・コントローラには含まれない．
実装
以下のステップ1~6は必須であり，7~10は自由度を高める際に行う．
- Human-Computer Interactionとアプリの中核となる機能を分離する
- 更新伝播メカニズムを実装する
- ビューを設計，実装する
- コントローラを設計，実装する
- ビュー・コントローラ関係を設計，実装する
- MVCのセットアップを実装する
- ビューの動的生成
- プラガブルコントローラ
- 階層化されたビューとコントローラのためのインフラストラクチャ
- システム依存部分との結合度を低くする
バリエーション
- ドキュメント-ビュー
適用例
結論
MVCパターンの利点
- 同一モデルに対する多重視点
- 1つのモデル対して複数のビューを使える
- 同期されたビュー
- プラガブルビューとプラガブルコントローラ
- MVCが概念分割を支援するので，ビュートコントローラが可換となる
- ルック&フィールの拡張容易性
- フレームワークの可能性
