MVPとUserControlsおよび呼び出し

Question

ユーザーコントロールに関係しているため、MVPの一部に頭を悩ませようとしています。私は.NET WinForms（またはそれに近いもの）と、Supervisoring Controllerパターンを使用しています（まあ、私はそう思う:)。

ユーザーコントロール自体がMVPアプリケーションの一部です（ビューであり、プレゼンターなどが関連付けられています）。プレゼンターは常に最初に開始され、モデルを開始してからビューを開始します。ビューはそのUIを構築します。その一部はビューであるUCを新しくすることです。

（フォーム）プレゼンターはUCプレゼンターについて知る必要がありますが、ビューの構成方法については何も知らないと思っています。たとえば、フォームプレゼンターは、UCがフォームのControlsコレクションの一部であることも、それをすべきでないことも知りません。

さらに、デザインエクスペリエンスを変更しないでください。 IOWビュー（フォーム）の開発者は、ツールボックスからユーザーコントロールを選択し、フォームにドロップすることができます。

それでは、私の質問に進みましょう。まず、上記の仮定は正しいですか？やや見当違い？めちゃめちゃ？ WTFを考えていますか？

第二に、フォームビューでUCビューを呼び出し、フォームプレゼンターがUCプレゼンターを呼び出して、プレゼンターがUCビューに何かを伝えるメカニズムがあるのは（十分ですか？）これにより、「最初にプレゼンター」が壊れます。ルールですが、他にそれを行う方法がわかりません。

その他の考え、提案、コメントは喜んで受け入れました。

-nwahmaet

Answer 1

プレゼンターは「自律状態」と見なされるべきです。プレゼンテーション層。これは、モデルの状態のビューの表示が同期していることを確認する責任があることを意味します。これを取り上げる理由は、「パターン」がMVPの多くは、物事をどのように分離すべきかという独断的な見方で失われます。これが、Martin Fowlerが MVPパターンに関する用語を明確にしようと決めた理由の1つと思われます。

私のお気に入りのMVPのフレーバーはパッシブビューであるため、私の答えはそれに基づいています。

パッシブビューパターンを使用して、複合ユーザーコントロールとフォームを頻繁に実装します。基本的に3つの異なる構成があります：

1. 階層内のすべてのユーザーコントロールに対して1人のプレゼンター。インターフェイスを使用してビューをフラット化します。
2. 複合ツリーの各ユーザーコントロールに1人のプレゼンター。各親プレゼンターは、子プレゼンターのインスタンス化と初期化を担当します。ユーザーコントロールは設計時に作成され、プレゼンターなしで（プレゼンテーション動作なしで）機能できます
3. 複合ツリーの各ユーザーコントロールに1人のプレゼンター。すべてのプレゼンターは、より高いレベルのコントローラークラスを介して疎結合されます。コントローラークラスは、プレゼンターの解釈、配線、イベントの調整を行います。

それは私にとって最後の手段の解決策ですが（その複雑さのため）、最後の選択肢はあなたが探している解決策だと思います。

Answer 2

作業中のアプリケーションで、数か月間この問題に直面しています。私が最近ついてきた結論は、多くの場合、ウィンドウとユーザーコントロールの両方のレベルで、「中断」せずにMVPパターンを適用することは不可能だということです。パターン。

それについての私の考えは、ユーザーコントロールはビュー実装の一部であり、プレゼンターはビュー実装内で何が起こっているのかを知るべきではないということです。コントロールのプレゼンター。したがって、前者による後者のインスタンス化を含めて、コントロール間のプレゼンターは存在しないはずです。ユーザーコントロールのプレゼンターはウィンドウビューの実装の一部であり、ウィンドウビューがユーザーコントロールのプレゼンターをインスタンス化する可能性があると主張されるかもしれません。しかし、ビューはそれらを認識してはならないため、プレゼンターが必要とするモデルクラスを注入することはできません。

私が到達していると思う結論は、すべてのユーザーコントロールはビュー実装に固有であり、より大きなパターンのビューサイロ内に完全に含まれる必要があるということです。そのため、彼らは独自のプレゼンターを持つことはできません...少なくともコントロールの実装自体にバンドルされていません。代わりに、ビューインターフェイスで公開されるパススルーフィールドを介して、親ウィンドウのプレゼンターが間接的に操作する必要があります。つまり、ユーザーコントロールは、独自のインターフェイスではなく、親ビューによって実装された共通のパススルーインターフェイスを介してプレゼンターに公開されます。これを「部分ビューインターフェイス」と呼びます。

その後、プレゼンターは、この部分ビューインターフェイスと、モデルの関連部分のみで機能する再利用可能なサブプレゼンタークラスのインスタンスを含めることができます。これにより、コントロールを使用する必要があるたびにモデルから変換するプレゼンターコードを書き直すことを回避でき、コントロールのプレゼンターに情報を渡すためにウィンドウビューがモデルについて知る必要がなくなります。

これが効果的に行うことは、ユーザーコントロールをモジュールとして、データモデルからさらに分離することです。これは、ユーザーコントロール全体をビュー実装の要素と考える場合に意味があります。再利用可能なユニットとして、ビュー機能の一部であり、その一部をデータモデルに関連付けないでください。

Answer 3

一般的な質問ですが、さまざまなスキームが適用できます。

この場合、私の推測では、オブザーバーパターンを確認する必要があります。

そのビューを使用するものが実装するインターフェースがあります。その後、アプリケーションがこれらのインターフェイスのコレクションで初期化されると、それ自体を登録します。そのビューを更新する必要があるコマンドは、各ビューを更新する必要があることを通知するコレクションを走査します。

典型的な例とは異なり、ビューはユーザーコントロールになります。ユーザーコントロールに加えてダイアログ、フルフォームなどを使用できるように、UI要素にそのインターフェイスを実装させる柔軟性があります。

最後に、ユーザーコントロールはビューではなく、ビューの実装であることを忘れないでください。どのスキームを採用するにしても、ビューの深さを自由に定義し、ユーザーコントロールにそのインターフェイスを実装させることができます。