神話上のMVCの狩り。 概要、ソースへの戻り、テンプレートを分析して表示する方法

「人々がこのカルーソを賞賛する理由がわかりませんか？」 舌で縛られて、グーグルで、歌って-何も理解できません！

「カルーソの歌を聞いたことがありますか？」

-はい、私は彼のレパートリーから何かを得ましたラビノビッチは電話で歌いました。

ITに基づく探偵。 パート1

Model-View-Controllerトピックに関する別の記事を書くのは愚かで、カルマにとって有害で​​あることに気付きました。 しかし、私はこの「パターン」とはあまりにも個人的な関係を持っています-失敗したプロジェクト、半年の人生、そして「バスケットで」のハードワーク。

MVCなしで、原則に基づいてプロジェクトを書き直しました-コードはスパゲッティのボールのように見えなくなり、半分にカットされました（これについては、プロジェクトでの「原則」の適用方法についての約束の記事で詳しく説明します）。 しかし、私たちが何を間違えたか、何が間違っていたかを理解したかったのです。 そして、時間の経過とともに、略語MVCを含むすべてのものが研究されました。 クリエーターであるトリグヴェ・レーンスカウガのオリジナル作品が出会うまで...

そして、すべてが所定の場所に落ちました。 実際、原則に基づいて、「オリジナルMVC」を再発明したことが判明しました。 そして、MVCとしてしばしば提示されるものは、それとは何の関係もありません...しかし、良いアーキテクチャと同様に。 そして、「クラシックMVC」の破産について何人の人が書いているかを判断し、それについて議論し、あらゆる種類の修正を考案し、この問題に遭遇したのは私たちだけではありません。

30年以上にわたり、MVCで収集されたアイデアとソリューションは、ユーザーインターフェイスの開発にとって最も重要なものです。 しかし、奇妙なことに、既存の混乱と矛盾する解釈の豊富さにもかかわらず、開発者は中古情報に満足し続け、ウィキペディアからMVCの知識を引き出し、インターネット上の小さな記事とWebアプリケーションを開発するためのフレームワークを作成します。 最も「高度な」読み物はマーティン・ファウラーです。 そして、何らかの理由で、ソースを参照する人はほとんどいません。 このギャップを埋めたいと思います。 そして同時にいくつかの神話を払拭します。

神話：MVCはSmallTalk用に作成されました

MVCコンセプトは、1978/79年のゼロックスPARCでの作業の結果としてTrygve Reenskaugによって策定されました。 原則として、MVCの作成はSmallTalk言語に関連付けられていますが、これは完全に真実ではありません。 実際、ReenskaugはDynabookチームで、Alan Kay率いるすべての年齢の子供向けのラップトップコンピューターの開発に携わりました。

そのプロジェクトの規模と革命を評価するために、これらの年は、コンピューターで作業するために、複数ページのマニュアルを勉強し、学位を取得する必要があった年であったことに留意する必要があります。 Alan Kayが解決しようとしていたタスクは、コンピューターと平均的なユーザーを近づけ、それらを隔てる壁を「壊す」ことでした。 彼はユーザーに非常にシンプルで便利なツールを提供したかったが、同時にコンピューターと複雑なアプリケーションの制御を可能にした。

その後、グラフィカルインターフェイスの基礎が築かれ、「フレンドリーなインターフェイス」の概念が形成されました。 また、SmallTalk言語は、オブジェクト指向プログラミングの概念とともに開発されたため、訓練されていないユーザーは「プログラムを理解して記述できます」。 Steve Jobsが 1979年にXerox PARCで見たものについて説明します-Steve JobsがXEROXからGUIのアイデアを得た方法 （6.30から）

このプロジェクトは、非常に強力な開発者のグループによって約10年間続けられています。 ユーザーインターフェイスの分野、およびオブジェクト指向プログラミングの分野、そして一般に大規模で複雑なコンピューターシステムの開発の両方の結果として見つかったソリューション、アプローチ、原則は、Reenskaugによってある程度まとめられ、MVCの基礎を形成しました。 ですから、MVCは、まず第一に、一連のガイドアーキテクチャのアイデアです。 SmallTalk-80では、これらのアイデアが初めて意味のある実装になりました。 さらに、これはReenskaugがゼロックスPARCを離れた後、彼の参加なしで行われました。

残念ながら、長い間、「実際のMVC」に関する情報はほとんどありませんでした。 クリエーターからの最初の本格的な出版物は、わずか10年後に登場しました-「 Smalltalk-80でModel-View-Controllerユーザーインターフェイスパラダイムを使用するためのクックブック 」。 ファウラーでさえ、MVCをSmallTalkの作業バージョンで研究したと述べています。「MVCを学習できるように、Smalltalk-80の作業バージョンにアクセスできました。この研究は徹底的であるとは言えませんが、ソリューションのいくつかの側面を理解することができました他の説明で説明できませんでした 。 "

ですから、「神話」やさまざまな解釈の出現は驚くことではありません。 問題は、多くの「セカンダリ」ソースがMVCを歪んだ形だけでなく、一見単純化された形式、通常は特定の形式の形式で記述することです。

その結果、多くの人々はMVCをスキームまたはパターンと本当に考えています（その理由は常に疑問が生じているためです-既存の多くのスキームのどれが「正しい」のか、なぜそんなに多いのか）。 より高度なバージョンでは、MVCは複合パターンと呼ばれます。つまり、複雑なアプリケーションを実装するために一緒に動作する複数のパターンの組み合わせです（ここでは、Observer、Strategy、Compositeについて説明します）。 また、MVCは主に、さまざまなテンプレートを使用してさまざまな方法で実装できるアーキテクチャのアイデア/原則/アプローチのセットであることを理解している人はごくわずかです...

後者には、特にMartin Fowlerが含まれます。 彼は次のように書いています。 「MVCはしばしばパターンと呼ばれますが、多くの異なるアイデアが含まれているため、パターンとしてそれを認識することには特別な利点はありません。 さまざまな人々がさまざまなソースでMVCを読み、そこからさまざまなアイデアを引き出していますが、それらを同じもの、つまり「MVC」と呼びます。 これは多くの混乱を招き、加えて、MVCの誤解や誤解の原因にもなります。まるで「損傷した電話」でMVCを見つけたかのように。 MVCと呼ばれるものを自分で見つけられなかった回数を見たことがあります。」 [GUIアーキテクチャ]

「損傷した電話」の理由の1つは、「舞台裏」の副次的な情報源のほとんどが最も重要なものを残していることです-作成者がMVCに定めた非常に建築的なアイデアと、彼らが解決しようとしたタスクです。 MVCの本質を理解し、膨大な数の落とし穴とエラーを回避できるようにするすべてのもの。 そのため、この記事では、通常「舞台裏」に残っているもの、つまり、MVCに組み込まれたアーキテクチャの原理とアイデアの観点から説明します。 スキームもありますが。 むしろ、それらから始めます。

しかし、最初のリンク。 Reenskaugの元のレポートは「 元のMVCレポート 」です。 後に、レンスカウグはこれらすべてをより明確に定式化し、その後の研究「 モデル-ビュー-コントローラー（MVC） 」で設計しました。 その過去と現在 。」 おそらく誰かが、その期間に関連するRenskaugの記録が収集されているページに興味を持っているでしょう。彼のコメント-MVC XEROX PARC 1978-79 。

開発者によるSmallTalk-80言語でのMVCについての既述の最初の出版物は、 「 Smalltalk-80システムのModel-View-Controllerユーザーインターフェイスパラダイムの説明 」（Glenn KrasnerおよびStephen Pope）のみです。 また、記事「 Smalltalk-80でのアプリケーションプログラミング 」も参考にしてください。 Model-View-Controllerの使用方法 」（SteveBurbeckは、Smalltalk-80に基づいたIBM向けSmallTalkコンパイラの開発、およびMacAppの開発に貢献しました）。 まあ、誰かが完全な没入を望んでいるなら-“ Smalltalk-80。 Reenskaugがモデル、ビュー、コントローラーという用語を作成した際の議論で有名なAdele Goldberg の対話型プログラミング環境 。

MVCスキーム

これが何であり、問​​題が何であるかを明確にするために、最初に最も典型的なMVC「スキーム」を分析しましょう。 これは重要なことです。なぜなら、多くの場合、ダイアグラムには説明が与えられず、定義はある場所から借用され、ダイアグラムは別の場所から借用されるからです。 その結果、まったく異なるダイアグラムを持つ同じMVC記述を見つけることができますが、これは非常に紛らわしいです。

そのため、MVCは非常に異なる方法で解釈および描写されているという事実にもかかわらず、この多様性のすべてにおいて、共通の「コア」を選択することができます。 一般的なことは、特定の方法で接続されているモデル、ビュー、コントローラーの3つの部分について言われていることです：

1. モデルはビューまたはコントローラーについて何も認識していないため、独立したコンポーネントとして開発およびテストできます。 そして、これがMVCのハイライトです。

   
   
   
   
   
   
   

2. ビューにモデルが表示されます。 そして、それは彼が何らかの形でそこから表示に必要なデータを取得しなければならないことを意味します。 次の2つのオプションが最も一般的です。1） アクティブビュー 。モデルを認識し、モデルから必要なデータを取得します。 2） パッシブビュー 。データはコントローラーによって提供されます。 この場合、ビューはどのような方法でもモデルに接続されていません。

   
   
   
   
   
   
   

   いくつかのタイプがあります。たとえば、テーブルまたはグラフの形式など、異なる方法で同じデータを表示したり、モデルのデータの異なる部分を表示したりすることができます。

   
   
   
   
   
   
   
3. コントローラーはおそらく最も物議を醸すコンポーネントです。 それにもかかわらず、コントローラーは常にモデルについて知っており、モデルを変更できることがよくあります（通常はユーザーのアクションの結果として）。

また、ビュー/種（特に複数ある場合）を管理し、それに応じて種について知ることもできますが、これは必須ではありません。

ここから、MVCの最も一般的な2つの種類の基本的な（最大限に単純化された）スキームを取得します。 取り消し線は、コントローラーとビューのオプションの接続を示します。

これは、ファウラーの基本図のように見えます。「モデル、ビュー、コントローラー間の主な接続。実際、ビューとコントローラーは互いに直接接続できるため、基本と呼びます。ただし、開発者は通常この接続を使用しません。 ） "：

次。 ビューなどのモデルは、パッシブまたはアクティブにすることもできます。 パッシブモデルは、ビューやコントローラーには一切影響しません。 この場合、モデルへのすべての変更はコントローラーによって監視され、コントローラーは必要に応じてビューを再描画する責任があります。

しかし、通常、MVCは依然としてアクティブモデルオプションを意味します。

「アクティブモデル」は、変更が発生したことを通知します。 そして、 Observerテンプレートを介してこれを行い、すべての「サブスクライバー」に変更通知を送信します。 アクティブビューはこれらのメッセージ自体にサブスクライブするため、モデルから必要なデータを再読み込みして更新するタイミングがわかります。 「パッシブビュー」の場合、サブスクライバーはコントローラーであり、コントローラーがビューを更新します。

オブザーバーテンプレートを使用すると、モデルは一方では変更が発生したことをビューまたはコントローラーに通知し、他方では実際にそれらについて「何も知らない」ことができます（ただし、特定の指定された「サブスクライバー」インターフェイスを実装することを除く）。 これはウィークバインディングと呼ばれ、MVCの2番目のキーポイントと見なされます。

そのため、MVCが複合テンプレートであると言われる場合、まず第一に、 Observerパターンがそのコンポーネントの1つとして言及されます。 図では、通常、弱い結合は破線の矢印で描かれますが、多くはこの規則を無視します。

したがって、より高度な「MVCスキーム」は次のようになります。

注： パッシブモデルとアクティブモデルという用語にまったく異なる意味を入れている著者がいます。 つまり、通常、Thinモデル（データのみを含むモデル）およびTolstoyモデル（アプリケーションのすべてのビジネスロジックを含む本格的なモデル）と呼ばれるものです。

さて、最後。 一般的に、MVCは、そのバリエーションのいずれにおいても、主にユーザーインターフェイスを備えたアプリケーションを開発するためのテンプレートであり、その主な目的はアプリケーションとユーザーの相互作用を保証することです。 そのため、 ユーザーは（明示的または暗黙的に）本格的なMVCスキームに参加している必要があります。 そして、ここで基本的に2つの解釈が見つかりました：

1. ユーザーはコントローラーを介してアプリケーションを制御し、ビューはモデルに関する情報を表示するためだけに機能し、ユーザーはそれを見るだけです

   
   
   
   
   
   
   

   

   
   
   
   
   
   
   

   多くの場合、ユーザーがコントローラーを操作することだけを示しますが、彼が見るものは表示されます。

   
   
   
   
   
   
   

2. ユーザーはビューとのみ対話します。 つまり、ビューはモデルを反映するだけでなく、ユーザーコマンドを受信して​​コントローラーに渡します。 この場合、ViewとControllerの間に別の接続が形成されます：直接（ViewはControllerを認識し、情報を直接転送します）または、ほとんどの場合、弱められます（Viewは単にユーザーアクションに関する情報をすべての関心のあるサブスクライバーに送信し、Controllerはこのニュースレターを購読します）

   
   
   
   
   
   
   

   

   
   
   
   
   
   
   

注： パッシブビューのオプションは、ビューがモデルとまったく接続されておらず、コントローラーが表示用のデータを提供する場合、MVCと呼ばれることがあり、別のバージョン-MVPに分割されてからコントローラーがプレゼンターに名前が変更されることに留意する必要があります。

上記のすべてを説明するために、「インターネットからの」いくつかの図を示します（これらが非常に異なる理由がより明確になることを望みます）。

そして今、最も重要なこと-それらはどのように適用され、それらは何を意味し、モデルビューとコントローラーはアプリケーションを記述するときに何に対応しますか？

ここでは、根本的に異なる2つのアプローチを区別できます。それぞれのアプローチでは、モデル、ビュー、コントローラーが非常に異なる方法で解釈されます。

Webからの「3層MVC」

最初のアプローチは、MVCが最も広く使用されているWebプログラミングに由来するため、Webプログラミングに特徴的な機能を可能な限り反映しています。 つまり、3層アーキテクチャ「クライアント-サーバー-データベース」へのバインドとスクリプト言語の普及。 その結果、MVCコンポーネントは、アーキテクチャの3つの層に正式にバインドされ、次のことがわかりました。

1. モデル=データベース
   
   モデルは、アプリケーションが動作する単なるデータです

   
   
   
   
   
   
   

2. コントローラー=サーバー
   
   コントローラは、アプリケーションのビジネスロジックです。 時には、コントローラーはすべての要求と意思決定の処理の中心であり、モデルとビューの間の接続を提供する中間層であると言うことさえあります。

   
   
   
   
   
   
   
3. 表示=クライアント （通常は薄い）
   
   ビューはユーザーインターフェイスです。 さらに、この場合のインターフェイスは、原則として、主に「デザイン」としてのみ理解され、単なるグラフィック要素のセットです。 このインターフェイスのロジックとデータを操作するロジックは、コントローラーに転送されます。

このアプローチの不適切さについてはすでに多くのことが書かれているので、Wikipedia（ MVC。最も一般的な間違い ）にさえ入っています。 よく詳細に発生する問題については、古典的な「 MVCのM：モデルが誤解され、過小評価されている理由 」になった記事で説明されています。 したがって、私は簡単に簡単に要約しようとします：

1. モデルの独立性はMVCの中心です。 モデルが薄い場合、つまりデータのみが含まれている場合、その独立した開発の可能性はほとんど意味がありません。 したがって、このアプローチでは、MVC自体も無意味です。

   
   
   
   
   
   
   

2. アプリケーションのすべてのビジネスロジック、つまりコードの大部分はコントローラーに集中しています。これは、コントローラーがMVCで最も依存する部分であるという事実にもかかわらずです。一般に、モデルとビューに依存します。 一般的に言えば、適切に設計されたアプリケーションでは、彼らは正反対のことをしようとします-最も依存する部分は最大ではなく、最小でなければなりません

   
   
   
   
   
   
   

3. 実際には、Webアプリケーションのコントローラーは通常1つのスクリプトに対応し、実際にすべてのビジネスロジックをコントローラーに入れることは、アプリケーションのほとんどが1つのスクリプトにあることを意味します。 これがTTUKという用語の由来です。太くてumbいコントローラです。

   
   
   
   
   
   
   
4. 原則として、モデルが薄いだけでなく、ビュー（ダムビューまたはダムインターフェイス-ダムGUI、ダムビュー）も薄いため、結果として、コントローラーにはアプリケーションのすべてのビジネスロジックに加えてユーザーインターフェイス制御ロジックも含まれます。 つまり、このアプローチでビジネスロジックとプレゼンテーションロジックを分離する代わりに、それらは混同されます。

もちろん、プログラムはWebアプリケーションのページに対応する多くのMVCに分割され、これにより状況は保存されますが、残念ながら本質は変わりません。 この問題は既知であり、ここに良い記事があります-「 RIA Architecture 」。

一般的なエラー：ビジネスロジックコントローラーとGUIロジックの混在

良いニュースは、ほんの数年前に最も一般的だった「MVCのWebバージョン」が、現在積極的に地位を失っていることです。 悪いニュースは、それがまだ一般的であるということです。今では明示的にではなく、変装した形でのみです。 フレーズに関して（引用）：「 モデルはデータベースなどとのデータ交換です 。 このデータを処理し、ビューの準備をするコントローラーロジック 」は現在、積極的に「マイナス」であり、次のように書き始めています。

• モデルは、データとそれらを操作する方法です
• コントローラー-ユーザーアクションとユーザーが入力する情報の処理

実際、オブジェクト指向アプリケーションにはデータはありませんが、多くのオブジェクトがあり、それぞれにデータとそれらを操作する方法が含まれています。 データベースへのアクセスオブジェクト（存在する場合）を含みます。 したがって、モデルの定義が「データ」という単語で始まる場合、本質的にはほとんど意味がなく、多くの場合、ベール形式ではデータベースへのすべての同じアクセスを意味します。 ユーザーアクションの 処理では、ビジネスロジックの大部分が配置されることが多く、その結果、すべてまたはほとんどすべてのアプリケーションロジックがコントローラーに配置されることがよくあります。

「建築MVC」

2番目のアプローチは、ソースにより近いものです。 したがって、より詳細に分析します。

Martin Fowler氏は、MVCはパターンではなく、カスタム情報システム（通常は複雑な）の構築に使用される一連のアーキテクチャの原則とアイデアであると言っています。

「 プログラムアーキテクチャの作成またはスツールの設計方法 」の記事で、アーキテクチャの原則を収集して説明しようとしました。 簡単に言えば、本質は次のとおりです。複雑なシステムはモジュールに分割する必要があります。 さらに、分解を階層的に行うことが望ましく、システムが分割されるモジュールは、可能であれば、独立または疎結合 （ 低結合 ）である必要があります。 接続が弱いほど、プログラムの作成/理解/展開/修復が容易になります。 したがって、分解の主なタスクの1つは、コンポーネント間の結合を最小化し、弱めることです。

ユーザーアプリケーションのプライマリアーキテクチャ（分解）を作成するために、これらの原則がMVCでどのように適用されるかを見てみましょう。 基本的に、MVCは3つのかなり単純なアイデアに基づいています。

「1」ユーザーインターフェイスからのアプリケーションのドメインモデル（ビジネスロジック）の分離

MVCの最初の主要な考え方は、最初の近似として、ユーザーアプリケーションを2つのモジュールに分割できることです。1つはアプリケーションの主要な機能、ビジネスロジックを提供し、2つ目はユーザーインタラクションを担当します。

したがって、システムのビジネスロジックを含み、ユーザーとの対話方法を考えることなく、アプリケーションの機能コアを構成するドメインモデルを開発する機会が得られます。

ユーザーと対話するタスクは、別のモジュール（ ユーザーインターフェイス ）で実行され、比較的独立して解決することもできます 。

「アーキテクチャMVC」のモデルと見なされるのは、ドメインモデル（英語のドメインモデルのドメインモデル ）です（そのため用語）。 したがって、独立しており、独立して開発およびテストできることが非常に重要です。

「MVCのコアアイデア、および後続のすべてのフレームワークのコアアイデアは、 分離プレゼンテーションと呼ばれるものです。分離ビューの意味は、実世界を反映するドメインオブジェクト間に明確な線を引くことです。画面上のGUI要素であるプレゼンテーションオブジェクト。ドメインオブジェクトは完全に独立しており、プレゼンテーションを参照せずに動作する必要があります。また、複数の表現をサポートする必要があります。 ところで、このアプローチはUnix文化の重要な側面の1つでもあり、今日でもコマンドラインとグラフィカルインターフェイス（同時に）の両方を介して多くのアプリケーションで動作することができます。 -ファウラー

「2」 オブザーバーテンプレートによるモデルの独立性とユーザーインターフェイスの同期

2番目の重要なアイデアは、モデルを独立して開発できるようにするために、ユーザーインターフェイスへの依存を弱める必要があるということです。 そして、上記のように、 Observerテンプレートによりこれが行われます。

モデルは変更通知を送信します 。 インターフェイスはこれらのアラートをサブスクライブするため、モデルからデータを再読み込みして更新するタイミングがわかります。 これにより、「オブザーバー」インターフェイスを実装することを除いて、それに関連付けられたユーザーインターフェイスについて何も知らない、ほぼ独立したモデルが得られます。

「3」ビューとコントローラーへのユーザーインターフェイスの分離。

3番目のアイデアは、単純に階層分解の2番目のステップです。 アプリケーションをビジネスモデルとインターフェイスに最初に分離した後、次の階層レベルで分解が続行され、ユーザーインターフェイスがViewとControllerに分割されます。

この部門の本質を理解し、それに応じて説明できる人はほとんどいないという印象を受けました。 通常、コントローラーはユーザーのアクションに何らかの形で応答する標準の合理化された定式化のみを提供し、ビューはモデルを表示します（したがって、ほとんどの実装では、ビューはモデルの変更の通知にサブスクライブします。一緒にコントローラー）。

ビューとコントローラーへのユーザーインターフェイスの分割は、 階層の第2レベルに属しているため、ドメインモデルとインターフェイスへのアプリケーションの最初の分離よりもはるかに重要ではありません。 ( ) « MVC », UI-, . .

« MVC» . , , , . , . , -, " ", .

«Original MVC»: SmallTalk-80

, MVC , « » . , , ?

? «MVC-» , - ?

, , . , ( ) . , , , . , . , , , GUI, .

— , . : " A model could be a single object (rather uninteresting), or it could be some structure of objects. " – , , ?

: " , … « », - , ." « ». «» , « ».

: , ( ), «» ( ) «». , , .

, « » «». , , , , . – « ». . (Dependency Inversion Principle). — .

, , .

:

: MVC , , , « », , «Editor» ().

, MVC , – ( ), ( ). «MVC » ( ), .

, ( ), , . - , , , . , , … , -, , . .

MVC, :

. . / . , , . .

- , -. , ( ), . ( Provided Interface ) ( RequiredInterface ).

,

( Interface Segregation Principle ) ProvidedInterface RequiredInterface .

, . , — “ An API Gateway is a server that is the single entry point into the system. It is similar to the Facade pattern from object-oriented design. The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client . ” Building Microservices: Using an API Gateway .

" API, API (Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client. For example, the Netflix API gateway runs client-specific adapter code that provides each client with an API that's best suited to it's requirements) " API Gateway .

- SmallTalk-80. - MVC :

… (glue), , , , … / .

, . - ( "Interface-Based Programming Techniques").

- JavaGuru — Advanced MVC Patterns . , , /-/ (Models as Proxies, Models as Filters), , – , : “ , , . !.. - ”.

- , original MVC, «», . « », .

— " ?". MVC — «-» .

? , . しかし、これは理論上です。 - . – « » «GUI » ( ).

, Smalltalk. Smalltalk-80 . ( « » ) , , .

( SmallTalk) /, . - ( ) SmallTalk-80.

, Smalltalk GUI : Inspector, Browser, Workspace,…

Glenn Krasner:

"Inspector . ListView (), TextView ()… « Inspector »… « Inspector » . View " actual " models ...

Inspector, . « Browser » - ... "

: -, -, . Inspector « Inspector », Browser – « Browser ».

Workspace, " StringHolder, , ".

Krasner SmallTalk ( Model): StringHolder , Browser , Inspector , FileModel , Icon … " the models were almost always some sort of filter class ".

VisualWorks Smalltalk Holder- . , , – ValueModel ValueHolder. , , ValueModel , GUI « » .

:

, " MVC" - GUI - . Front-Controller ApplicationModel, ViewModel ( . Model-ModelView-Controller ) Proxy-model .

- , «», , . - -.

たとえば、ValueHolderは通常、既存のドメイン変数の単なるラッパーです。データを含めるべきではなく、データへのリンクを含める必要があります。 それらは次のとおりです。「 ValueModelは、別のモデルによって既に格納されているため、実際に値を格納する必要はありません 」（ ValueModelの理解と使用 ）。

Advanced MVC Patternsの記事からの引用です：「 Swingコンポーネントを使用するときによくある間違いの1つは、これらのSwingコンポーネントのモデルにデータをコピーすることです。正しい方法は、既存のデータを使用し、フィルター...覚えておいてください：単に解釈できるデータをコピーしないでください！ "

次の簡単な例を考えてみましょう。 インターネットのヒントに従って、次のようなコード（StackOverflowおよびJListのアイテムの追加と削除から取得 ）を使用して「リストにアイテムを追加」すると、まったく同じデータがリストモデルにコピーされます。

Object[] items; //  

DefaultListModel model = new DefaultListModel();
JList list = new JList(model);
for (int i = 0; i < items.length; i++){
     //      !
     model.addElement(items[i]);  
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

, , ListModel ( AbstractListModel):

//  -   ,
//      
ListModel model = new AbstractListModel() {
    public int getSize() {return items.length;}
    public Object getElementAt(int index) {return  items[index];}
};
//       
JList list = new JList(model);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

, - , . -

Object[] items1;  Object[] items2; //  

// -   
ListModel model = new AbstractListModel() {
    public int getSize() { return items1.length + items2.length;}
    public Object getElementAt(int index) {
        return index<items1.length ? items1[index] : items2[index-items1.length];
    }
};
JList list = new JList(model);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

. , ( ).

, :

JList list = new JList(items);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

- .

: GUI-

 

, .

: «MVC »

- «» . - , , .

- (, , ) , . : "model object with a façade that reflects the user’s mental model".

MVC «», « » . (" ?", “ ?”), .

MVC , : . //..., ( ) . – .

概して、この中間オブジェクトがどの用語と呼ばれ、どのModel-View-WhateverタイプのMVCが使用されているかはまったく同じです。

原則として、この記事は完了できます。既に述べたように、ユーザーインターフェイスをViewとControllerに分割することは、最も重要ではなく、補助的な瞬間です。しかし、一方で、ユーザーインターフェイスはすべてのユーザーアプリケーションに存在し、この分野で開発されたアプローチやアイデアのアイデアを持っていると便利です。さらに、主要な議論が行われているのはコントローラーです。したがって-2 番目の部分は、このトピック専用です。