Loading article…
モデル・ビュー・コントローラ（MVC ）は、関連するプログラムロジックを相互接続された3つの要素に分割する、ユーザーインターフェースの開発によく使用されるソフトウェアアーキテクチャパターン[ 1 ]です。これらの要素は次のとおりです。
従来はデスクトップのグラフィカルユーザーインターフェース（GUI）に使用されていたこのパターンは、 Webアプリケーションの設計で人気を博しました。[ 4 ]人気のあるプログラミング言語には、このパターンの実装を容易にするMVCフレームワークがあります。
グラフィカルユーザーインターフェースの初期開発における重要な洞察の一つであるMVCは、ソフトウェア構成要素をその責任の観点から記述および実装する最初のアプローチの一つとなった。[ 5 ]
トリグヴェ・リーンスカウグは、 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年、元PARC職員2名によるThe Journal of Object Technology （JOT）の記事で、 MVCがSmalltalk-80開発者向けの一般的な「プログラミングパラダイムおよび方法論」として紹介されました。しかし、彼らのスキームは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開発者の間で人気を博しました。Spring（2002年10月リリース）などのJava向けフレームワークも、JavaとMVCの強い結びつきをさらに強固なものにしました。
2003 年、マーティン・ファウラーは『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 ]これはリチャード・ポーソンの著書『ネイキッド・オブジェクト』で詳しく説明されています。[ 40 ]
PARCでMVCを考案したTrygve Reenskaugは、「MVCは、大規模で複雑なデータセットをユーザーが制御するという問題に対する一般的な解決策として考案された」と述べている。[ 6 ]
カールトン大学のコンピュータサイエンス教授であるウィルフ・ラロンドとジョン・ピューは、1991年の著書『Inside Smalltalk』の中で、Smalltalk-80スタイルのMVCの利点を次のように説明している。
元々はデスクトップ コンピューティング向けに開発された MVC ですが、主要なプログラミング言語でワールド ワイド ウェブアプリケーションの設計として広く採用されています。このパターンを強制するウェブ フレームワークがいくつか作成されています。これらのソフトウェア フレームワークは、主に MVC の責任がクライアントとサーバー間でどのように分割されるかという点で、解釈が異なります。[ 42 ]初期の MVC フレームワークは、ほぼすべてのモデル、ビュー、およびコントローラー ロジックをサーバー上に配置するシン クライアントアプローチを採用していました。このアプローチでは、クライアントはコントローラーにハイパー リンクリクエストまたはフォーム送信を送信し、ビューから完全で更新されたウェブ ページ(またはその他のドキュメント) を受け取ります。モデルは完全にサーバー上に存在します。[ 42 ]後期のフレームワークでは、 Ajaxを使用してデータを同期し、MVC コンポーネントをクライアント上で部分的に実行できるようになりました。
より深く言えば、このフレームワークは情報の表現とユーザーとのやり取りを分離するために存在します。
モデルは、制限なくあらゆるオブジェクトにすることができます。
では、モデルがエンタープライズ オブジェクト クラスとリレーショナル データベースに格納されているデータとの間の対応関係を確立し、維持します。
、データベースのproductsテーブルにマッピングされたモデル
が作成されます。
Product一般的に、各モデルは単一のデータベース テーブルにマッピングされます。
オブジェクトの視覚的な表現を提供する役割を担います。
ビュー オブジェクトは、ユーザー インターフェイス上に表示されるもの (たとえば、ウィンドウやボタン) を表します。
ビューをより大きなユニットに組み立てるための部品として使用することができ、既存のビューをサブビューとして使用して新しい種類のビューを構築できます。
ビュー オブジェクトは再利用性が非常に高く、アプリケーション間の一貫性を提供します。
アクション ビューのテンプレートは、HTML と混在するタグ内に埋め込まれた Ruby を使用して記述されます。
テンプレートには、目的の HTML 出力の静的な部分と、動的なコンテンツを挿入する方法を記述する特別な構文が含まれています。
通常、ビューは関連付けられたコントローラーアクションと同じ名前を持ちます...
ビューはモデルとコントローラについて明示的に認識しています。
アプリケーション内でモデル オブジェクトとビュー オブジェクトの間の仲介役として機能しているのは、コントローラ オブジェクトです。
では、Web リクエストはアクション コントローラーとアクション ビューによって処理されます。通常、アクション コントローラーはデータベースとの通信と、必要に応じて CRUD アクションを実行することに関係します。アクション ビューは、レスポンスをコンパイルする責任を負います。
Django では、「ビュー」はどのデータを表示するかを記述しますが、ビューは通常、データがどのように表示されるかを記述するテンプレートに処理を委譲します。
ユーザーとモデル／ビュー間のインターフェースを担います。キーボードの文字入力に加え、マウスの動きやクリック操作を解釈します。
通常、ビューは関連付けられたコントローラーアクションと同じ名前を持ちます...
