WinformsソリューションのMVPを設定するにはどうすればよいですか？
私は過去にMVPとMVCを使用しましたが、MVPのほうが実行の流れを非常によく制御できるので、私の意見ではMVPを好んでいます。 インフラストラクチャ（データストア/リポジトリクラス）を作成し、サンプルデータをハードコーディングするときに問題なく使用できるので、GUIに移行してMVPを準備しています。 セクションA エントリポイントとしてビューを使用するMVPを見ました。つまり、ビューコンストラクターメソッドでプレゼンターを作成し、次にプレゼンターがモデルを作成し、必要に応じてイベントを関連付けます。 プレゼンターは、ビュー、モデル、プレゼンターが作成されるエントリポイントとしても見てきました。このプレゼンターには、コンストラクターでビューとモデルオブジェクトが与えられ、イベントを結び付けます。 2と同じですが、モデルはプレゼンターに渡されません。代わりに、モデルはメソッドが呼び出され、応答が直接返される静的クラスです。 セクションB 私が見たビューとモデルの同期を保つという点で。 ビューの値が変更されたとき、つまりTextChanged.Net / C＃のイベントが発生したとき。これDataChangedEventにより、モデルに渡されるa が起動され、常に同期が保たれます。そして、モデルが変化する場所、つまり、モデルがリッスンするバックグラウンドイベントの場合、ビューはを上げるという同じアイデアによって更新されDataChangedEventます。ユーザーが変更をコミットSaveEventしようとすると、モデルが起動して保存されます。この場合、モデルはビューのデータを模倣し、アクションを処理します。 ＃b1と同様ですが、ビューは常にモデルと同期しません。代わりに、ユーザーが変更をコミットしたい場合に起動SaveEventされ、プレゼンターは最新の詳細を取得してモデルに渡します。この場合、モデルは、それに基づいて行動する必要があるまでビューデータを認識しません。その場合、必要なすべての詳細が渡されます。 セクションC ビュー内のビジネスオブジェクト、つまりプリミティブデータ（int、double）ではなくオブジェクト（MyClass）の表示 ビューには、ドメイン/ビジネスオブジェクトとして表示されるすべてのデータのプロパティフィールドがあります。ビューはこれらをTreeViewのノードに処理しますが、プロパティをview.Animals公開するなどIEnumerable<IAnimal>。次に、選択した動物について、プロパティSelectedAnimalとして公開しIAnimalます。 ビューはドメインオブジェクトの知識を持たず、プリミティブ/フレームワーク（.Net / Java）に含まれるオブジェクトタイプのみのプロパティを公開します。この場合、プレゼンターはアダプターオブジェクトにドメインオブジェクトを渡し、アダプターは特定のビジネスオブジェクトをビューに表示されるコントロールに変換します。この場合、アダプターは、ビューだけでなく、ビューの実際のコントロールにアクセスできる必要があるため、より緊密に結合されます。 セクションD 単一のコントロールを作成するために使用される複数のビュー。つまり、さまざまなタイプのオブジェクトを保存するような単純なモデルを持つ複雑なビューがあります。適切なコントロールが表示される項目をクリックするたびに、メニューシステムを横に配置できます。 ビューインターフェイスを介して公開される個々のコントロールすべてを含む1つの巨大なビューを作成します。 いくつかのビューがあります。メニュー用のビューとブランクパネルが1つあります。このビューは、必要な他のビューを作成しますが、表示しません（visible = false）。このビューは、含まれる各ビュー（子ビュー）のインターフェイスも実装するため、1人のプレゼンターに公開できます。空白のパネルには、他のビュー（Controls.Add(myview)）および（(myview.visible = true）が表示されます。これらの「子」ビューで発生したイベントは、親ビューによって処理されます。親ビューは、イベントをプレゼンターに渡し、逆もまた同様です。 メインビューであれ小さなビューであれ、それぞれのビューは、それぞれ独自のプレゼンターとモデルに配線されます。ビューコントロールを既存のフォームに文字通りドロップするだけで、機能の準備が整い、舞台裏でプレゼンターに配線するだけで済みます。 セクションE すべてにインターフェースがある場合、上記の例でMVPがどのように行われるかに基づいて、相互互換性がない可能性があるため、この回答に影響します。 すべてには、View、Presenter、Modelというインターフェースがあります。これらのそれぞれは、明らかに具体的な実装を持っています。具体的なビューが1つしかない場合でも、モデルとプレゼンター。 ビューとモデルにはインターフェースがあります。これにより、ビューとモデルが異なります。プレゼンターは、ビューおよびモデルオブジェクトを作成/指定され、それらの間でメッセージを渡すだけです。 ビューのみにインターフェースがあります。モデルには静的メソッドがあり、作成されないため、インターフェースは不要です。別のモデルが必要な場合、プレゼンターは静的クラスメソッドの別のセットを呼び出します。モデルは静的であるため、プレゼンターへのリンクはありません。 個人的な考え 私が提示したすべての異なるバリエーション（ほとんどはおそらく何らかの形で使用しました）から、さらに多くのバリエーションがあると確信しています。A3は、MVPの外でビジネスロジックを再利用可能に保つこと、A2はデータの重複を減らし、発生するイベントを減らすことを好みます。C1は別のクラスに追加しないため、少量のユニットテスト不可能なロジックをビューに入れます（ドメインオブジェクトの視覚化方法）が、これはコードレビューするか、アプリケーションで単に表示することができます。ロジックが複雑な場合、アダプタークラスに同意しますが、すべての場合に同意するわけではありません。セクションDの場合、D1はメニューの例としては大きすぎるビューを作成すると感じています。以前にD2とD3を使用しました。D2の問題は、イベントをプレゼンターとの間で適切な子ビューにルーティングするために大量のコードを記述する必要があり、ドラッグ/ドロップ互換性がないことです。新しいコントロールごとに、単一のプレゼンターをサポートするためにより多くの配線が必要です。D3は私の好みの選択肢ですが、ビューが非常に単純であるか、再利用する必要がない場合でも、ビューを処理するプレゼンターおよびモデルとしてさらに多くのクラスを追加します。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。 質問 MVPを正しく実装していますか？適切な方法はありますか？ バリエーションのあるマーティン・ファウラーの作品を読んだことがあり、MVCを始めたとき、コンセプトを理解していましたが、エントリポイントがどこにあるのか、すべてが独自の機能を持っていますが、オリジナルを制御して作成するものは元々理解できませんでしたMVCオブジェクトのセット。