モデル・ビュー・コントローラ - Trygve Reenskaug

この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。(原文公開日:1979年12月10日)


モデル

モデルは知識の表象です。モデルは1つのオブジェクトであるかもしれませし(あまり面白くはありませんが)、複数のオブジェクトからなる構造かもしれません。


モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。


モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード(例えば、カレンダーの予定)を実装の詳細(例えば、パラグラフ)と一緒にすることは混乱を招きますし、良くない形式と考えられます。

ビュー

ビューはモデルの(視覚的な)表象です。普通は、モデルが持つ特定の属性を強調し、それ以外のものを抑制します。このように、ビューはプレゼンテーションフィルタとして機能するのです。


ビューはモデル(あるいはその一部)に付随し、プレゼンテーションに必要なデータを、モデルに問い合わせることで取得します。同様に、適切なメッセージを送信することでモデルを更新することもあります。こうした問い合わせとメッセージはすべて、モデルを構成する用語法の中に含まれていなければなりません。(例えば、モデルの識別子を要求した際には、テキストのインスタンスが返されることを期待するのは良いですが、モデルがテキストクラスであると想定すべきではありません。)

コントローラ

コントローラはユーザとシステムとを紐づけるものです。ユーザに対するインプットは、対応するビューを画面の適切な場所に表示させることによって提供し、ユーザがアウトプットするための手段としては、メニューやその他コマンドやデータを送るための手段を表示させます。コントローラはこうしたユーザからのアウトプットを受け取り、適切なメッセージに変換した上で、1つまたは複数のビューへ引き継ぎます。


コントローラは決してビューを補完すべきではありません。例えばノードのビューの間に矢印をひくことでそれらをつなげるということをしてはならないのです。


逆に、ビューはマウス操作やキーボード操作のようなユーザからの入力について知っているべきではありません。ユーザからの一連の指示を正確に再生するメッセージを送信するようなメソッドは常にコントローラに書くことができなければなりません。

エディタ

コントローラはそのビューすべてと紐づいているため、これらのビューはコントローラの一部と呼べます。ビューによっては特別なコントローラ、すなわちエディタを提供するものもあります。これはユーザがビューに表示された情報を修正できるようにするものです。このようなエディタはコントローラとビューをつなぐルートに接合され、コントローラの延長として機能します。編集のプロセスが完了すれば、エディタはそのルートから取り外され、破棄されます。


追記しておくと、エディタは紐づけられたビューのメタファーを通じてユーザとコミュニケーションします。したがってエディタはビューと密接に関係しているのです。コントローラがエディタを取得する際にはビューに問い合わせを行います。エディタを保持する適切な場所は他にありません。



翻訳者解説

これは1978〜1979年というMVCの黎明期に行われた議論を経て、まさに"Model-View-Controller"という用語が定義された際のドキュメントです。30年前のものということもあって、実装や責務分割という点から見ると現在とは異なっているところもあります。特にエディタについては現在ではビューの延長として考えられており、コントローラは複数のビューの生成、制御とユーザからの入力の処理を受け持つことになっています。Reenskaug氏のサイトより現在のMVCを表した図を引用します。


MVC illustration.


このように多少古くなっている部分もあるのですが、注目すべきは「知識の表象としてのモデル」、「モデルの一部を視覚的に切り取ったものとしてのビュー」、「モデルの用語を使ったユーザとのコミュニケーション」といった、後のドメインモデルへとつながる思想が既に凝縮されている点です。モデルは生まれた瞬間から「モデル」だったということですね。