wpf - 複数のビュー間でViewModelの1つのインスタンスを共有することにはメリットがありますか？

Question

私の同僚の1人は、VMがシングルトンのように使用され、それぞれが複数のビューに同時に接続されるという非常に奇妙なアプローチを提供しています。
データアクセス層でキャッシュする代わりに、一種のデータ共有以外に、このような奇妙さの長所は見当たりません。
私はこれを実際に見たことがありませんが、それだけでアイデアを拒否したくありません。

PS私は、1つのVMに異なるビューを適用することではなく、1つのインスタンスを共有することについて話します。

ありがとう。

Answer 1

このアプローチは、ビューの同期を維持し、同じように見えるようにする場合に役立つと思います。そうでなければ、私はそれが混乱することに同意します。

現実の世界で使用されているシングルトンビューモデルを見たのは、単一インスタンスでもあるビューがある場合だけです。つまり、常にビューのコピーを1つだけ開くことができます。その場合、ビューを再度開くたびにビューモデルを再作成する必要がないため、パフォーマンス上の利点があります。

Answer 2

理論的には、ビューごとにビューモデルが必要ですが、場合によっては、異なるビューに同じビューモデルを使用すると便利な場合があると思います。たとえば、さまざまなアプリケーションの場所にユーザーを表示していて、アプリケーションの場所でUser.Nameが変更されたときに、ユーザーが表示されている他のすべての場所でもUser.Nameも変更されたとします。この通知の問題については、ビューモデルを1つだけにして、INotifyPropertyChangedインターフェイスを使用してすべてのビューに通知することをお勧めします。これはあなたの同僚が望むかもしれないことだと思いますが、アプリケーションの複雑さを増したり、予期しない動作を引き起こしたりする可能性があるため、これを使いすぎるのはよくありません。

Answer 3

必ずしも「シングルトン」ビューモデルと呼ぶかどうかはわかりませんが、場合によっては、複数のビューコントロール間でビューモデルインスタンスを共有したいと思います。たとえば、これは、詳細に加えた変更によってマスターパーツの視覚的な外観が変わる可能性があるマスター/詳細シナリオで非常に役立ちます。たとえば、選択したアイテムの詳細を表示する編集パネルが横にあるリスト/ツリービュー。もちろん、2つのVM間でメッセージを渡すことでこの種のことを行うことはできますが、VMを再利用するよりもコードを追加する可能性が高いようです。

完全にシングルトンのVMを使用することをお勧めしないのは、変更を加えるために開くダイアログのように、詳細編集がモーダルであるある種のマスター/詳細シナリオが必要な場合です。そこで、キャンセルのサポートを容易にするために、編集を別のインスタンスにカプセル化する必要があります。アプリケーショングローバル（静的など）のシングルトン実装は、そのようなことを非常に厄介にします。