現在、MVVMデザインパターンには多くのバリエーションがありますが、理解しているとおり、ビューはビューモデルに依存することが許可されています。私の同僚は同意しませんが、彼は満足のいく説明をすることができませんでした。MVVMのViewとViewModel間の依存関係
など。私のビューにはビューモデルへの参照が含まれています。これはすべてのビューで必要というわけではありませんが、特定のイベントをICommandで実行できないビューモデルに伝えるときに役立ちます。
この依存関係は問題ありませんか？欠点は何ですか？
主な指標は次のとおりです。をテストできますか？
ビュー絶対ににはビューモデルへの参照が必要です。どのようにそれはそれ自身が表示する必要がある情報を得るだろうか？通常、ビューのDataContextのビューモデルを持つだけで十分ですが、依然として依存関係になります。 DataContextのVMがなければ、ビューは役に立たなくなります。
時にはビューをVMにコールバックする必要がある場合があります。通常、私はコードの背後でこれを行います：
public MyViewModel ViewModel
{
get { return DataContext as MyViewModel; }
}
private void _someEventHandler(object sender, EventArgs)
{
ViewModel.SomeMethod();
}
ビューモデルからビューへの参照を保持することは、注意が必要なところです。 VMが特定のビューの実装に依存している場合、VMはビューに密接に結合されており、結果としてテストすることは困難です。
VMがビューとやりとりする必要がある場合は、要件をインタフェースに抽象化して、ビューにそのインタフェースを実装させることができます。次に、ビューがロードされると、VMが相互作用できる自己への参照をVMに提供できます。
データバインディングだけで結合するのは本当にいいですが、ビューにはビューモデルのコマンドやプロパティより多くのものが必要になることがあります。ビューモデル内のイベントに応答する必要があるビューがあり、これらのイベントをルーティングイベントにすることはできません。したがって、このビューにはビューモデルへの参照が必要です。
通常、DataContextChangedイベントの内部のDataContextを正しいインターフェイスタイプにキャストしようとするとよいと思います。この方法では、データテンプレートやその他のXAMLを通じてビューを初期化することができます。インターフェイスを強制的にコンストラクタで渡す場合は、コードでビューを作成する必要があります。
そして、ケントのようにインターフェースを介して話す理由は、あなたがテストのためにこれを模擬することができるということです。テストの目的のためにこのインタフェースを実装するダミービューを作成することができます。 –