私はMVPを使用するWinFormsアプリケーションを持っています。新しいUI要素を作成する必要があるときのシナリオにどのようにアプローチするのかが完全にはわかりません。UI要素は誰が作成する必要がありますか？
例えば、私のビューには新しいビュー（フォーム）をダイアログとして開くはずのボタンがあるとします。ビューまたは発表者が新しいビューを作成することになっていますか、それともプレゼンターの仕事ですか？
これは私の思考プロセスである：
これは正しいアプローチですか？
私はこれがいくつかの異なる方法で行われていることを見てきました。すべてのパターンが紙の上で完璧に見えるのは面白いですし、実装の詳細はそれがいかに簡単でないかを示しています。私はMVW（モデルビュー - 何でも）として例を挙げるつもりです。なぜなら、それはどのパターンでも似ているはずだからです。
オプション1： プロパティにバインドします。これはWinFormsではもう少し難しいですが、WPFでうまくいきます。プレゼンター/コントローラー/ビューモデルにボタンを設定してください。ビューは、この値に基づいてUIを表示または非表示にします。 UIは、既存のすべてのUIをオーバーレイしてモーダルの外観を持つことができます。
オプション2： サービス。 DialogServiceを導入してください（うまくいけば、依存性注入をセットアップして、追加するのは簡単です）。このサービスには、ShowDialog（オプション）のメソッドがあります。オプションには、タイトル、メッセージ、コマンド（ボタンのタイトルとアクション）があります。あなたのボタンにプロパティを設定させるか、プレゼンターにコマンドを発動させ、それからdialogServiceのShowDialogメソッドを呼び出します。このようにして、あなたの意見はまだ単にプレゼンターに電話しており、そのサービスを使用しています。ビューはサービスについて知ってはいけません。これによりDialogSeviceは適切なUIを構築し、新しいフォームを起動することができます。これはネイティブのMessageBox.Show呼び出しをまとめてDialogServiceで置き換えることができるようにする方法です。
オプション3： 純真ではありません。あなたのモーダルがプレゼンターと対話する必要がないか、単純に基本データを元に戻したい場合（カラーピッカーなど）、あなたのビューがそれを世話するようにします。あなたのボタンは単にモーダルを開くことができます、モーダルはビューに返される値を持っています。その後、あなたのビューはそれらを使用します。データにプレゼンターに戻す理由がない場合は、過度のことを純粋主義者として複雑にしないでください。ビューはUIベースのロジックを実行できます。私は、マウス/タッチイベントでの要素の移動や、ズーム計算のためのピンチなど、多くのUIのためだけにビューを使用します。ロジックがUIのみの場合は、ビューのコードの背後に保持します。繰り返されるUIロジックの場合、それをサービス、ユーザーコントロール、またはカスタムビューに移動します。
すべてのMVP/MVC/MVVMドキュメントでは、常に重要な詳細が欠落しています。私にとって、サービスは欠けているリンクです。彼らは疎結合されたロジックをプラグインすることができ、醜いUIバインディングやUIイベントのいくつかをサービスにまとめて整理することができます。
これが役に立ちます。
まあ、それは本当に依存しています。ビューの作成を一般化することができれば、Pのスコープになる可能性があります。そのようなビューがビジネス・ロジックに影響を与えない場合、ビューは、プレゼンターがそれらと対話することを必要としないビュー自体を作成することがあります。たとえば、Googleマップの単純なアプリケーションを使用している場合、Googleマップインスタンスは_main_プレゼンターと対話できる内部ビューを作成して、サブビューがプレゼンターとやりとりしていることを知らせなくてもかまいません。 2番目の方法はP <-> Vの相互作用をより複雑にするので、私はデフォルトで最初のものに行きます。 –
ビューのどれも私が知っている限り（今はとにかく）ビジネスロジックに影響を与えません。 MVPに関する私の理解は、UIと関係があり、ビュー内で行われるべきであり、プレゼンターはビューとモデルのプロパティを操作するだけでなく、UI要素を作成する必要があります。 – Jake