2

これが以前に尋ねられた場合は申し訳ありませんが、助けが見つかりませんでした。

監視コントローラーの MVP パターンを使用して作成された複雑な winform の良い例があるかどうか疑問に思っていました。私は多くの例を読みましたが、それらは実際には単純で、1 つのフォームと 1 つのモデルしか扱っていません。

私が探しているのは、あるビューから別のビューにデータを渡す方法と、通信回線をどこに配置し、何を何にバインドする必要があるかを示す例です。

次のような UI があるとします: 代替テキスト http://img12.imageshack.us/img12/2683/layoutcroped.jpg

怪しげな UI モックアップで申し訳ありません。基本的に、各ユーザー コントロールには独自のプレゼンターとモーダル レイヤー オブジェクトがあります。

私がする必要があるのは、ユーザー コントロール 1 のテキスト ボックスの入力を取得し、(ユーザー コントロール 1 のプレゼンターで) サービス オブジェクトを使用してデータベースから適切なアイテムを取得し、モーダルとしてユーザー コントロール 2 に渡すことです。

私の質問は次のとおりです。ビュー インターフェイスを介してモデルをユーザー コントロール 2 に渡すか、そのプレゼンターに渡しますか?

これが理解しにくい場合は申し訳ありませんが、MVP パターンを使用するユーザー コントロールでフォームを使用できるが、2 つの間でデータを渡す方法についての例が見つからないという人をよく見かけます。

編集: 私は2つの異なるものを作成しましたが、これができると思いました:

と

Ex1 の方が優れていると思います。彼らがやりたいことをするために。

どう思いますか？

ありがとう。

4

4 に答える 4

1

監視コントローラーは、ステートフル モデルを使用し、オブザーバー/オブザーバブル メカニズムを介してビューをすぐに同期する必要がある場合に使用されます。 .

監視対象コントローラー

ビューは、プレゼンター (直接) とモデル (イベント経由) の両方によって表示を更新するように求められることに注意してください。ほとんどの場合、ビューはモデル状態の単純な変更に応答し、それ自体を更新します。より複雑なロジックが関係する場合、プレゼンターはアプリケーション ルールに従ってビューを変更する責任を負います。

たとえば、UserControl1 はプレゼンターを介してモデルにデータを送信し、モデルはすべての登録済みビューに変更を通知します (それらをモデルに送信して、それに応じて更新します)。

それが役立つことを願っています。

于 2009-07-27T16:23:22.530 に答える
1

これにアプローチする方法は、イベント指向のパブリッシュ/サブスクライブ アプローチです。

パターンは次のようになります。

  1. ユーザーが最初のビューで [編集] ボタンをクリックすると、単一のパラメーター (ID、この場合はテキスト ボックスの値) を使用してイベント (コマンドと呼ぶことができます) が発生します。イベントを「EditRequested」と呼びます。これはイベントの「公開」であり、これが発生したことと詳細を知りたい人に伝えます。実際の公開は、コントローラー/プレゼンターで行われる場合があります。

  2. 2 番目のビューのコントローラー/プレゼンターは上記のイベントをリッスンし、イベントが発生するとそれに応じて動作し、データを読み込み、イベント パラメーター (ID) を使用して編集モードに切り替えます。これは、パターンの「サブスクライブ」部分です。

理想的には、これはイベント アグリゲーター (Prism と同様に CAB が提供します) を使用して実行されますが、おそらく単一のケースに対して手動で何かを行うことができます。イベント アグリゲーターにより、パブリッシャーとサブスクライバーが互いを認識する必要がなくなり、疎結合が改善されます。

于 2009-07-26T15:24:09.887 に答える
0

特定のプレゼンテーションに必要なものを調整（および監督）する専任のプレゼンターを1人持つという観点から考えるのが最善だとあなたが言っていることから、私は思います（つまり、「顧客情報の収集」）。次に、モデル（または十分な複雑さがある場合はそのファサード）をそのプレゼンターに渡して構築することを考えてください。

ユーザーコントロールに、それ自体がモデルに緊密に結合されているプレゼンターがある場合（テキストボックスが表面に表示されない場合）、そのモデルをそのプレゼンターに渡すことはできますが、ビューには渡しません。インターフェース。

プレゼンテーションの作成を支援する機会を得るために、現在ユーザーコントロールと呼んでいるものについてもう少し知る必要があります。

あなたが具体化し始めているシナリオを釘付けにする1つの例はわかりませんが、Fowlerのサイトにあるさまざまなmvpの例に焦点を当て、JeremyMillerのBuildYourOwnCabシリーズを見ていきます。どちらも問題をすぐに解決できないため、どちらも少しイライラしますが、どちらもこの幅広いトピックの側面についての洞察を提供します。

それが役に立てば幸い！ベリル

于 2009-07-09T04:30:18.657 に答える
0

この件に関して、いくつかの深刻な問題がありました。最初は、最初のビューが 2 番目のビューの作成と構成を担当し、最初のプレゼンターが 2 番目の作成と構成を担当すると想定しました。このソリューションは、多くの理由で不適切でした。まず、2 番目のビューは他の 2 つのオブジェクト (1 番目のビューと 2 番目のプレゼンター) によって構成されました。2 番目の欠点は、ビューを結合し、ビューに論理的な責任を持つことでした。

私たちはしばらくの間解決策を探していましたが、このバインディングを緩めてプレゼンターで実行する必要があると判断しました。そのため、指定された ID (文字列または GUID) に一致するビューとプレゼンターのファクトリ クレート ペアを作成しました。ユーザーがビューで何らかのアクションを実行すると、この呼び出しがプレゼンターに転送され、どのペアを表示するかが決定されます。

于 2009-07-09T07:00:31.103 に答える