モデルビュープレゼンター（MVP）
MVPアーキテクチャはIBMで初めて登場し、1990年代にTaligentシステムでより明確に登場しました。 これは、Potelの作業で十分に詳細に説明されています。 このアイデアはDolphin Smalltalkの開発者によって取り上げられました。 後で見るように、これら2つの作品はまったく同じことを言っているわけではありませんが、それらに埋め込まれたアイデアは非常に人気があります。 アーキテクチャを説明するときに、これら2つのソースを参照します。
MVPの説明を始めるには、UI開発の2つの柱の重要な違いについて考えるのが便利です。 一方は、「フォームと要素」、UIデザインの主流であるアーキテクチャです。 一方、MVCとその派生物。 「フォームと要素」モデルは、開発者にわかりやすいデザインを提供し、再利用可能なコントロールとアプリケーションのビジネスコードを簡単に分離できるようにします。 彼女は、 ドメインモデルの使用によって駆動される豊富な分離されたプレゼンテーションとプログラミングコンテキストでMVCが持っているものを見逃しています。 私は、MVPをこれらの2つのモデルの組み合わせであり、それらを最大限に活用する試みだと考えています。
Potelによると、MVPでのプレゼンテーションは、「Forms and Elements」モデルのフォームコントロールの構造として理解されるべきであり、コントロールからコントローラ\ビューへの分離は削除されるべきです。 ビューには、要素とユーザーの対話方法を決定する動作を含めないでください。
この相互作用は、別のオブジェクト表現（プレゼンター）で実行されます。 基になるコントロールイベントイベントはビューに残りますが、それらの目的はコントロールをプレゼンターに転送することです。
プレゼンターは、イベントへの対応方法を決定する必要があります。 Potelは、この相互作用を、コマンドおよびサンプルのシステムを通じて発生するモデル上のアクションの観点から定義します。 ところで、このアプローチに注意してください-すべてのモデルエディションをチームにまとめる。 これにより、元に戻す/やり直し動作（元に戻す/やり直し）を簡単に入力できます。
モデルからビューへの逆更新は、MVCで使用されるアップデーター（ Observer Synchronization ）による同じ同期を通じて行われます。
同様の説明がDolphinによって定義されています。 プレゼンターオブジェクトも必要です。 ただし、Dolphinはプレゼンターインタラクションシステムとモデルを定義しません。 さらに、プレゼンターがビューに直接アクセスできる必要があることを明確に示唆しています。 Potelは、プレゼンターがビューにアクセスできるかどうかについては何も述べていませんが、Dolphinにとっては、前のセクションで説明した偏差色のアプリケーションモデルの問題のために、この動作は非常に重要です。 あなたが覚えているように、それは私の観点から、そのような厄介な方法で解決されました。
MVPを理解するための他のキーの1つは、プレゼンターがビュー内の要素を制御するアプローチを認識することです。 一方では、Potelはすべてのビューロジックをビューに残し、プレゼンターはモデルを定義すべきではないと主張します。 Gentlemen BowerとMcGlashanは彼らのソリューションを提供します 。 このソリューションでは、ほとんどすべてのプレゼンテーションロジックもビューで定義されますが、プレゼンターは複雑なシナリオでこのロジックに影響を与えることができます。 つまり プレゼンテーションロジックの一部はプレゼンターに配置できます。
さらに、すべてのプレゼンテーションロジックをプレゼンターに完全に転送して、 パッシブビューと呼ばれるものを取得できます 。 当初、パッシブビューはMVPモデルの一部ではありませんでした。 このモデルは、後に人々がテストの問題を解決することを学んだときに現れました。 このモデルについては後で説明しますが、今のところはMVPのタイプの1つであるとしか言いません。
MVPと上記で説明した他のすべてとの違いを決定する前に、言及した作品についていくつかの言葉を述べたいと思います。 それらはMVPとMVCの違いを決定しますが、私が見ている方法ではありません。 Potelは、MVCのコントローラーは共通のコーディネーターであると主張しています-私はこれに同意しません。 DolphinはMVCの問題について多くのことを語っており、MVCによっては、VisualWorksアプリケーションモデルを意味します。 私はこれを非難しません-私たちの時代では、古典的なMVCに関する情報を取得するのは非常に簡単ではありません。
ここで、MVPと以前のアーキテクチャの違いについて説明します（私が見たように）。
- フォームと要素：MVPにはモデルがあり、プレゼンターはビューを更新するときにObserver Synchronizationを使用してこのモデルを操作します。 また、発表者のコントロールへの直接アクセスは許可されていますが、このアクセスを使用するのは不適切な形式です。
- MVC：モデルを操作するために、MVPモデルは監視コントローラーを使用します 。 コントロールは、ユーザー入力を監視コントローラーに渡します。 コントロールは、ビューとコントローラーに分割されません。 プレゼンターはコントローラーと考えることができますが、ユーザー入力の初期処理はありません。 重要なことは、プレゼンターはコントロールではなくフォームレベルのオブジェクトであるということです-私の意見では、これはさらに大きな違いです。
- アプリケーションモデル：ビューは、アプリケーションモデルにイベントを渡すのと同じように、イベントをプレゼンターに渡します。 ただし、MVPのビューは、次のようにドメインモデルから直接更新できます。 プレゼンターはプレゼンテーションモデルではありません。 さらに、プレゼンターはコントロールに直接アクセスできる場合がありますが、これはObserver Synchronizationでは不可能です。
MVPプレゼンターとMVCコントローラーには明確な類似性があります。 プレゼンターは単なる緩い形式のコントローラーです。 その結果、多くのアーキテクチャはMVPパスに従いますが、プレゼンターを意味する「コントローラー」という用語を使用します。 一般的に、コントロールレベルでのユーザー入力との対話の問題が解決されると、コントローラーを使用する必要があります。
図12：MVPモデルの現在値更新シーケンス図
アイスクリームの例で現在の値を更新する方法を見てみましょう（図12 ）。 ダイアグラムの先頭は、「フォームと要素」にあるものと非常によく似ています。ユーザーが値を入力すると、テキストフィールドがイベント「text changed」を送信します。 プレゼンターはこのイベントを聞いてキャッチし、その後、プレゼンテーションから新しい意味を取ります。 次に、ドメインオブジェクトを更新し、拒否テキストフィールドで確認します。 偏差テキストフィールドは、計算された値で値を更新し、その後、色が割り当てられます。 色はプレゼンターを示します。 測定偏差カテゴリを読み取り、テキストフィールドの色を更新します（コントロールへの直接リンクを介して）。
MVPモデルを要約するには：
- ユーザーの操作（イベント）は、コントロールによって監視コントローラーに送信され、そこでさらに処理が行われます。
- プレゼンターは、ドメインモデルの変更を調整します。
- MVPのさまざまなバリエーションでビューを更新する実装は、さまざまな方法で実行されます。 メソッドの数は、ブラウザーを介した更新（ Observer Synchronization ）から始まり、各プレゼンターコントロールの手動更新で終了します。
次の部分はこちらです。