問題タブ [mediator]

些細なメッセージ（画像ビューアウィンドウを表示するなど）にメディエーターパターンを使用することは、プログラミングの良い習慣ですか？

単に使用する代わりに

私は自分のプログラムでメディエータープログラムをよく使用していますが、どれだけ多すぎるのか疑問に思いました。

よろしく、
セブ

誰かが2つの主な違いを指摘できますか?

少なくとも概念的には、この 2 つは非常に密接に関連しているようです。推測を危険にさらすとしたら、パブリッシュ/サブスクライブ メソッドはメディエーター パターンのサブセットであると言えます (メディエーターは必ずしもパブリッシュ/サブスクライブの方法で使用する必要はありませんが、後者には一種のメディエーターが必要なようです)物体）。それに近いところはありますか？

3つのステップでテキストファイルをアプリケーションにインポートする非常に単純なウィザードを作成する必要があり、メディエーターパターンを使用する必要があります。いくつかのサンプルアプリケーションまたはいくつかのチュートリアルやドキュメントがあるかどうか疑問に思っています。インターネットで検索しようとしましたが、例が見つかりませんでした。

2 つの ViewModel 間の通信の一般的なアプローチは次のとおりです。MVVM-View Model-View Model 通信

Mediator パターンまたは Messenger クラス。しかし、1 つのウィンドウに 6 つの ViewModel がある場合はどうでしょうか。

1. NewSchoolclassUserControl
2. NewPupilUserControl
3. SchoolclassListUserControl
4. 生徒リストユーザーコントロール
5. 生徒の詳細ユーザー コントロール
6. AdministrationButtonBarUserControl (コマンドを実行するボタンを持つ)

これはすべて 1 つのウィンドウにあります。6 つのビューとその Viewodel 用に Messenger をセットアップする必要があると「あなた」は本当に言いますか? それはひどいでしょう...

1 つのウィンドウに 6 つの UserControls がありますが、大規模なエンタープライズ アプリでさえ、1 つのウィンドウにそれ以上の UserControls があるわけではありません。

大きなmvvmアプリケーションの経験がある人の意見に興味があります:)

アプリケーションの他の場所で再利用したい UserControl+ViewModels のいくつか。したがって、すべてを 1 つの UserControl に入れることは、私が本当に望んでいることではありません。

更新：盲目のメイスのために;-)

@blindmeise

このViewModelは、実際にはDataGridにデータテンプレート化されています。期間は行です。各行には、ドキュメントと呼ばれる列があります。私は PeriodListViewModel 1 : N DocumentListViewModel を持っています。

DocumentListViewModel は、ListBox を含む UserControl でデータ テンプレート化され、いくつかのボタンの下に追加/削除/保存/開くなど...

DocumentListViewModel には、「LessonController」で実行されるコマンドとアクション デリゲートが含まれているため、追加、削除などのドキュメントに対するすべてのアクションは、LessonController で宣言された SelectedPeriodViewModel で実行できます。

上記のコードは、ユーザーが日付ピッカーで日付を変更したときに、データベースから新しいデータをロードするだけです。

もっとコードが必要ですか、それとも私のアプローチについて何と言いますか? 私は学ぶことに熱心で、すべての批評家に感謝しています!

CustomerListViewModel と OrderListViewModel があります。後者では、注文を選択して削除するか、新しい注文を作成します。どちらの状況でも、CustomerListViewModel と Messenger は IOrder 型に登録する必要があります。

ButtonBar に DateNavigatorViewModel + DateNavigatorView があります。

以下は、交換される 2 つのビューです: DailyView と WeeklyView。各ビューには、DailyViewModel と WeeklyViewModel があります。

私のDateNavigatorViewModelにはmessenger.Send(SelectedDate);

私の DailyViewModel と WeeklyViewModel では、それぞれコンストラクターに登録します。

日付を選択するとどうなるか...

MVVM Light ツールキットを使用しています。

データベースから2倍のデータを取得するという問題を解決するにはどうすればよいですか?

私が使用しているMessenger（mvvm light toolkit）の嫌いな点は、DateTimeに登録してアプリケーションの他の部分を送信すると、「DateTime」タイプに登録されているため、データ時間データも取得することです。

これを防ぐには、常にカスタムオブジェクトを作成し、日時の値をラップする必要があります。それは愚かです。

その問題をどのように回避しますか？

MVVM パターンを使用して WPF アプリケーションを開発しています。私はMVVM Lightライブラリを使用しており、依存性インジェクターも使用しようとしています(NinjectとUnityを検討しています)。

私は多くのブログ記事を読みましたが、クラスが相互に通信するための「適切な」方法についてかなり混乱しています。特に、いつ依存性注入を使用するか、いつメディエーター パターンに依存するかがわかりません。

例を考えてみましょう。私は ViewModel を持っています。それを DataViewModel と呼びましょう。また、ある種のデータを提供する Data クラスもあります。それらの間でどのように通信するのが良いですか：

A. IData のインターフェイスを使用して DataViewModel に依存関係を挿入しますか? この方法では、Data は Messenger に依存する必要はありませんが、Data が変更された場合はイベントを提供する必要があり、ViewModel はそれにサブスクライブする必要があります。

B. メディエーター パターン (MVVM Light で Messenger として実装) に依存し、Model と ViewModel の間でメッセージを送信しますか? この方法では、通信全体がメッセージに基づくため、依存性注入を使用する必要はまったくありません。

さらに、ViewModel は他の ViewModel に依存関係を注入する必要がありますか、それとも Messenger に依存する方がよいでしょうか? 最初の場合、ViewModel ごとに個別のインターフェイスを定義する必要がありますか? VMごとにインターフェースを定義するのは追加作業になると思いますが、その価値はあるかもしれません。

WPF/MVVMアルファオタクは次のように述べています。

1つのビューには1つのViewModelがあります。複数のビューに1つのViewModelがある場合があります（ウィザードを使用）。

私の画像を見ると、6色のViews/UserControlsが表示されます。

YELLOW、GREEN、ORANGE UserControlsは、私のアプリケーションで複数回使用されています。

ピンク、青、赤のUserControlは1回だけ使用されます。

質問：

1.それらもUserControlsにする必要がありますか？はいの場合、なぜそれらを再利用しないのですか。

2.これらが6つのUserControlであると想定しますが、同じViewModelを共有する必要がありますか？または、各ビューに独自のViewModelが必要ですか？

A.）GREENでクラスコードを作成するクラスコードをYELLOWに送信する

B.）黄色でクラスコードを選択します青色で現在の瞳孔を変更します

C.）青で現在の瞳孔を選択します赤で瞳孔の詳細を変更しますオレンジで瞳孔のドキュメントを変更します

D.）PINKで瞳孔を作成する瞳孔をBLUEに送る

E。）...もっとたくさん

関係を最新の状態に保つためにMessengerクラスを使用してデータを起動する方法はありますか？

私には大きな欠陥があります：

PupilViewModelを作成しましたが、NewPupilViewModel（PINK）でSchoolclassCodeViewModelがYELLOW UserControlに存在するかどうかわからないため、新しいPupilViewModelをBLUEUserControlに追加できます。

SchoolclassCodeViewModel 1：NPupilViewModel。

3.この問題をどのように解決しますか？

特定の状況でどのパターンに従うべきかを理解しようとしています。何らかの方法で相互にやり取りするいくつかのメイン ウィジェットで構成される Web アプリがあります。ウィジェットはモジュール パターンに従います。

コードを読み上げるには:

ご覧のとおり、ここには密結合があります。誰もが知っているように、密結合は悪です。(唯一無二のものを見つけた場合を除く! ;-))

pub-sub / カスタム イベント パターンに従うことで、多くのデカップリングを実現できることを私は知っています。しかし、A が何かを開始し、B が反応できる状況には、より適しています。しかし、A が独立して何かを開始する状況がありますが、続行するには B から特定の状態を確認する必要があります。

私は保守性を追求しているので、この地獄から抜け出す方法を探しています。

最初に頭に浮かんだのはメディエーター パターンです。

それでも、私のコードは次のようになります。

ウィジェットは直接通信するのではなく、メディエーターを介して間接的に通信するため、これは少し優れています。

ただし、私はまだ間違っていると感じており、ウィジェットを互いに切り離すためのより良い方法があるはずです。

編集

今までのことをまとめます！

一般的に、私はビューを分離する MVC アプローチが好きです! ただし、この例は複雑なモジュールのようなものだと考えてください。それらは、視覚的な意味で「ボックス」である必要はありません。このように説明する方が簡単です。

別の与えられた事実は、A が独立してアクションを開始し、その後何らかの状態をチェックする必要があるということです。B の状態変更をサブスクライブしてアクションを提供することはできません。Aが独立して開始し、特定の状態を確認する必要があるようにする必要があります。これは、B に要求する必要のある複雑な操作と考えてください。

そのため、カスタム イベント/コールバック/メディエーターのアプローチを組み合わせて思いつきましたが、それについて本当に気に入っている点がいくつかあります。

1.) モジュールは他のどのモジュールについても知りません
2.) モジュールはメディエータについても知りません
3.) 何らかの外部状態に依存するモジュールは、それが何らかの外部状態に依存していることだけを知っています - それ以上ではありません4.) モジュールは、誰がこの特定の状態を提供するかを気に
しません
。 5.) モジュールは、特定の状態が提供されたかどうかを判断できます
。 6.) 要求パイプラインはストレートです。つまり、モジュールはこの操作のスターターです。状態変更イベントをサブスクライブするだけではありません (A がアクションを開始し、B (またはどこか) からの状態が必要であることを思い出してください)。

ここにいくつかのサンプルコードを投稿し、jsFiddle も提供しています: http://jsfiddle.net/YnFqm/