XAMLのMVVM Lightのアプリケーションレベルでメッセージ受信者を登録していますか？

Question

具体的には、この場合、アプリケーション自体が受信者になります。私の思考プロセスでは、新しいViewが作成されるシナリオを扱うとき、ViewとView-Modelsの間のリンクをできるだけ少なくすることができます。メッセージを厳密に処理し、WPFアプリケーションのAppレベルでこれらのメッセージを処理します新しいビューを作成し、必要に応じてビューのDataContextを通じてモデルを暗黙的に表示します。

コードビハインド（app.xaml.cs）に入ると、これはわかります。しかし、私は理想的には、このメッセージ受信者の登録を処理するのが好きなのはxamlの動作がかなり単純なので、実際にはShowDialogを適切なビューに対して呼び出すだけです（これ以上の処理はできません私は何かを忘れているかもしれない）。

私の人生にとって、私はコードビハインドを避ける方法は考えられません（MVVMはコードビハインドの使用を実際に禁止していないことを知っています。他のMVVMの原則に違反することなく可能であれば、より良いコード構成を実現すると考えています）。 System.Windows.Interactivityの使用を検討し、EventTriggerをApplicationクラスのStartupイベントに結びつけたときに、それが機能するためにDependencyObjectを拡張する必要があることがわかったときに私はそれを持っていたと思いました。

要約すると、私の質問は2倍です。 A.ビューの作成を含むメッセージのサブセットに対して、app.xaml内のメッセージ受信者の登録を処理することさえ可能ですか。 B.これは試して適用するのに適した構造でも、他の見解に関連するメッセージの処理のための責任をどのように組織するかについての私の考えに基づいています。それが適切なアプローチでない場合は、より簡単な方法またはより良い方法がありますか？

Answer 1

Viewにはすべてのビュー関連のコードが含まれ、プログラムロジックは含まれていない必要があります。これはMVVM分離です。ビューでメッセージボックスを表示する必要がある場合は、Viewのコードで処理する必要があります。これは、Viewで定義されなければならないアニメーションと同じですが、コードの背後にある場合は簡単にできます。

MVVMLightメッセージでは、ViewModelが「これを見せたい」と言って、それを表示する方法を決定するための簡単な方法が許可されています。ViewViewは、必要な種類のメッセージを受信するためのレジスタであり、表示するUI部分を処理します。MessageBoxなどです。

純粋にXAMLで、おそらくもっときれいな方法でカスタムメッセージボックスを構築することでしょう。

パートBの場合：私はそれらを処理したいメッセージを受け取ります。