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

モデル・ビュー・コントローラ（MVC）は、関連するプログラムロジックを3つの相互接続された要素に分割するソフトウェア設計パターン^{[1]であり、}ユーザーインターフェイスの開発によく使用されます。これらの要素は次のとおりです。

• モデル、情報の内部表現
• ビュー、つまりユーザーに情報を提示し、ユーザーから情報を受け取るインターフェース
• コントローラーと、その2つをリンクするソフトウェアです。^{[2] [3]}

このパターンは、伝統的にデスクトップのグラフィカルユーザーインターフェイス（GUI）に使用されていましたが、Webアプリケーションの設計でも人気が高まりました。^[4]一般的なプログラミング言語には、このパターンの実装を容易にするMVCフレームワークがあります。

グラフィカルユーザーインターフェイスの初期開発における重要な洞察の1つであるMVCは、ソフトウェア構成要素をその責任の観点から記述および実装する最初のアプローチの1つになりました。^[5]

Trygve Reenskaug は、1970 年代後半にゼロックスパロアルト研究所(PARC)の客員研究員としてSmalltalk -79に取り組んでいるときに MVC を作成しました。 ^{[6] [7] [8] :  330}彼は、ユーザーが大規模で複雑なデータセットと対話するあらゆるプログラムを構造化するために使用できるパターンを望んでいました。彼の設計は当初、モデル、ビュー、モノ、エディターの4 つの部分で構成されていました。他の Smalltalk開発者と話し合った後、彼とグループの残りのメンバーは、モデル、ビュー、コントローラーに落ち着きました。^[6]

最終的な設計では、モデルは純粋に直感的にプログラムの一部を表します。ビューはモデルの視覚的表現であり、モデルからデータを取得してユーザーに表示し、ユーザーとモデルの間でリクエストをやり取りします。コントローラーは、画面上に複数のビューを配置して調整し、ユーザー入力を受け取り、適切なメッセージをその基礎となるビューに送信するユーザーインターフェイスの組織的な部分です。この設計には、特定のビューを変更するために使用される特殊な種類のコントローラーとして、そのビューを通じて作成されるエディターも含まれています。^[6]

Smalltalk-80 は、このバージョンから進化した MVC のバージョンをサポートしています。^[6]これは、抽象クラスviewとcontroller クラス、およびさまざまな汎用ウィジェットを表すそれぞれのさまざまな具体的なサブクラスを提供します。このスキームでは、はViewユーザーに情報を表示する方法を表し、はcontrollerユーザーが と対話する方法を表しますview。 はモデル オブジェクトにも結合されていますが、そのオブジェクトの構造はアプリケーションプログラマviewに委ねられています。Smalltalk-80 環境には、特定のモデル、ビュー、およびコントローラーの構造を並べて表示するための開発ツールである「MVC インスペクター」も含まれています。^[9]

1988 年、 2 人の元 PARC 従業員がThe Journal of Object Technology (JOT)に発表した記事では、Smalltalk-80 開発者向けの一般的な「プログラミング パラダイムと方法論」として MVC が紹介されました。しかし、彼らのスキームは Reenskaug らのスキームや Smalltalk-80 の参考書で紹介されているスキームとは異なっていました。彼らは、ビューをあらゆるグラフィカルな問題をカバーするものと定義し、コントローラーはより抽象的で、通常は目に見えないオブジェクトで、ユーザー入力を受け取り、1 つまたは複数のビューと 1 つのモデルのみと対話するものと定義しました。^[10]

MVCパターンはその後進化し、^[11]階層型モデル・ビュー・コントローラ（HMVC）、モデル・ビュー・アダプタ（MVA）、モデル・ビュー・プレゼンター（MVP）、モデル・ビュー・ビューモデル（MVVM）などのバリエーションが生まれ、MVCをさまざまなコンテキストに適応させました。

ウェブ アプリケーションにおける MVC パターンの使用は、1996 年にNeXTのWebObjectsが導入されて以来増加しています。WebObjects はもともとObjective-C (Smalltalk から大幅に借用) で記述されており、MVC の原則の強化に役立っています。その後、WebObjects がJavaに移植されたときに、MVC パターンは Java 開発者の間で人気を博しました。その後の Java フレームワーク、たとえばSpring (2002 年 10 月リリース) は、Java と MVC の強い結びつきを継続しました。

2003 年、Martin Fowler はPatterns of Enterprise Application Architectureを出版し、MVC を「入力コントローラ」がリクエストを受け取り、適切なメッセージをモデル オブジェクトに送信し、モデル オブジェクトから応答を受け取り、その応答を適切なビューに渡して表示するパターンとして紹介しました。^{[8] :  56}これは、 Ruby on Rails Web アプリケーション フレームワーク (2004 年 8 月)が採用したアプローチに近いもので、クライアントがブラウザ内ビューを介してサーバーにリクエストを送信し、これらのリクエストがサーバー上のコントローラによって処理され、コントローラが適切なモデル オブジェクトと通信します。^[12] Djangoフレームワーク (2005 年 7 月、Python用)は、同様の「モデル テンプレート ビュー」(MTV) パターンを提案しました。このパターンでは、ビューがモデルからデータを取得し、それをテンプレートに渡して表示します。^[13] Rails と Django はどちらも、迅速な展開に重点を置いてデビューしたため、MVC は長い間人気があった従来のエンタープライズ環境以外でも人気が高まりました。

パターンの中心となるコンポーネント。これはアプリケーションの動的データ構造であり、ユーザーインターフェースからは独立しています。^[14]アプリケーションのデータ、ロジック、ルールを直接管理します。Smalltalk-80 では、モデル型の設計は完全にプログラマに任されています。^[15] WebObjects、Rails、Django では、モデル型は通常、アプリケーションのデータベース内のテーブルを表します。^{[16] [17] [18]}モデルは、データを整理して一貫性を保つために不可欠です。これにより、アプリケーションのデータが定義されたルールとロジックに従って動作することが保証されます。

チャート、図、表などの情報の表現。管理者向けの棒グラフや会計士向けの表形式ビューなど、同じ情報を複数のビューで表示することも可能です。

Smalltalk-80では、ビューはモデルの視覚的表現に過ぎず、ユーザー入力を処理しません。^[19] WebObjectsでは、ビューはメニューやボタンなどの完全なユーザーインターフェイス要素を表し、ユーザーからの入力を受け取ります。^[20]ただし、Smalltalk-80とWebObjectsの両方で、ビューは汎用的で構成可能であることが意図されています。^{[21] [22]}

RailsとDjangoでは、ビューの役割はHTMLテンプレートによって担われ、そのスキームでは、ビューはユーザーインターフェースウィジェットを直接表すのではなく、ブラウザ内のユーザーインターフェースを指定します。^{[23] [24]} (Djangoは、この点を考慮して、この種のオブジェクトを「テンプレート」と呼ぶことにしました。^[25] ) このアプローチでは、小さく構成可能なビューにあまり重点が置かれていません。典型的なRailsビューは、コントローラアクションと1対1の関係を持っています。 ^[26]

Smalltalk-80のビューはモデルとコントローラの両方と通信しますが、^[27] WebObjectsでは、ビューはコントローラとのみ通信し、コントローラはモデルと通信します。^[28] RailsとDjangoでは、ビュー/テンプレートは、クライアントへの応答を準備するときにコントローラ/ビューによって使用されます。^{[29] [30]}

入力を受け取り、それをモデルまたはビューのコマンドに変換します。^[31]

Smalltalk-80 コントローラは、ボタンの押下やマウスの移動などのユーザー入力イベントを処理します。^[32]特定の時点では、各コントローラには 1 つのビューとモデルが関連付けられていますが、1 つのモデル オブジェクトは複数の異なるコントローラから情報を受け取る場合があります。特定の時点では、1 つのコントローラ (「アクティブ」コントローラ) のみがユーザー入力を受け取ります。グローバルウィンドウ マネージャオブジェクトは、現在のアクティブ コントローラの設定を担当します。ユーザー入力によってモデルが変更される場合は、コントローラはモデルに変更を通知しますが、モデルはビューの更新を指示する責任を負います。^[33]

WebObjectsでは、ビューがユーザー入力を処理し、コントローラがビューとモデルの間を仲介します。アプリケーションごとにコントローラが1つだけ、またはウィンドウごとにコントローラが1つだけ存在する場合があります。アプリケーション固有のロジックの多くはコントローラにあります。^[34]

Rails では、クライアントからサーバー上のアプリケーションに届いたリクエストは「ルーター」に送られ、ルーターはリクエストを特定のコントローラーの特定のメソッドにマッピングします。そのメソッド内で、コントローラーはリクエストデータや関連するモデルオブジェクトとやり取りし、ビューを使用してレスポンスを準備します。通常、各ビューには関連するコントローラーがあります。たとえば、アプリケーションにビューがある場合はclient、通常、関連するコントローラーもありますClients。ただし、開発者は必要に応じて他の種類のコントローラーを自由に作成できます。^[35]

Djangoでは、この役割を果たすオブジェクトをコントローラではなく「ビュー」と呼びます。^[30] Djangoのビューは、Webリクエストを受信して​​Webレスポンスを返す関数です。レスポンスを作成するためにテンプレートを使用する場合もあります。^[36]

アプリケーションをモデル、ビュー、コントローラコンポーネントに分割することに加えて、MVC設計パターンはこれら3つのコンポーネント間の相互作用を定義します。^[37]

• モデルはアプリケーションのデータを管理する役割を担い、コントローラーからユーザー入力を受け取ります。
• ビューは、モデルのプレゼンテーションを特定の形式でレンダリングします。
• コントローラーはユーザー入力に応答し、データ モデル オブジェクトに対してインタラクションを実行します。コントローラーは入力を受け取り、必要に応じて検証してから、入力をモデルに渡します。

他のソフトウェアパターンと同様に、MVCは問題に対する「ソリューションの核」を表現しながら、各システムに適応できるようにします。^[38]特定のMVC設計は、ここでの従来の説明とは大きく異なる場合があります。^[39]

アラン・ケイが2003年に書いたように、MVCの元々の目的は、あらゆるオブジェクトに対してグラフィカルなインターフェースを作成できるようにすることでした。^{[40]これはリチャード・ポーソンの著書}「Naked Objects 」で詳しく説明されています。^[40]

PARCのMVCの創始者であるTrygve Reenskaugは、「MVCは、ユーザーが大規模で複雑なデータセットを制御する問題に対する一般的な解決策として考案されました」と書いています。^[6]

カールトン大学のコンピュータサイエンス教授である Wilf LaLonde 氏と John Pugh 氏は、1991 年のガイド『Inside Smalltalk』の中で、Smalltalk-80 スタイルの MVC の利点を次のように説明しています。

• プレゼンテーションとデータの独立性、例えば1つのモデルを同時に複数のビューで表示など
• 構成可能なプレゼンテーションウィジェット（例えば、あるビューを別のビューのサブビューとして使用するなど）
• 実行中にコントローラーを別のコントローラーに交換することで、入力モードを切り替えることができます。
• コントローラとビューの責任を分離することにより、入出力処理の独立性を実現します。 ^[41]

MVCはもともとデスクトップコンピューティング用に開発されたものですが、主要なプログラミング言語でワールドワイドウェブアプリケーションの設計として広く採用されています。このパターンを強制するウェブフレームワークがいくつか作成されています。これらのソフトウェアフレームワークは、主にMVCの役割がクライアントとサーバー間で分割される方法で、解釈が異なります。^[42]初期のMVCフレームワークは、モデル、ビュー、コントローラーロジックのほぼすべてをサーバーに配置するシンクライアントアプローチを採用していました。このアプローチでは、クライアントはコントローラーにハイパーリンク要求またはフォーム送信を送信し、ビューから完全で更新されたウェブページ（またはその他のドキュメント）を受信します。モデルは完全にサーバー上に存在します。^{[42]その後のフレームワークでは、} Ajaxを使用してデータを同期することにより 、MVCコンポーネントをクライアント上で部分的に実行できるようになりました。

Wikibooks には、コンピュータサイエンス デザインパターン/モデル・ビュー・コントローラに関する書籍があります。