私のビューモデルクラスには、サービスに接続するメソッドがあります(それが良い習慣であるかどうか、またはビューモデルが厳密にプロパティおよびプロパティ変更メカニズムであると想定されているかどうかはわかりません)。もちろん、接続または切断するときに発生する可能性のあるWCF例外を処理したいと思います。
見つからないエンドポイントを例として使用してみましょう。これは、ユーザーの注意を引きたい例外です。大まかなコード例を考えてみましょう。
public void Connect()
{
ServiceClient proxy = null;
try
{
proxy = new ServiceClient();
proxy.Subscribe();
// ...
}
catch(EndpointNotFoundException)
{
// should I do something here?
}
// .. other WCF related exception catches and a finally
}
キャッチ内でSystem.Windows.MessageBox.Show()を直接呼び出すことは良い習慣と考えられますか、それともWPFアプリケーションの別のレイヤーがキャッチするように例外を再スローする必要がありますか?もしそうなら、そのような例外をキャッチするための理想的な場所はどこですか?
私はMVVMクライアントで例外をキャッチし、例外をキャッチしたErrorViewModel
のViewModel
プロパティでラップすることで例外を処理してきました。
ViewModel[〜#〜] a [〜#〜]がEndpointNotFoundExceptionをキャッチするとします。このエラーを表示するには、ExceptionをErrorViewModelでラップし、それを[〜#〜] a [〜#〜]のErrorプロパティに割り当てます。
[〜#〜] a [〜#〜]に関連付けられたビューには、[〜#〜] aにバインドされたContentControl
が含まれています[〜#〜]のErrorプロパティ。その間、私はDataTemplate
を使用してエラービューをErrorViewModelに関連付けます。そのビューでは、Visibility
は、[〜#〜] a [〜#〜]のErrorプロパティに例外が含まれているかどうかによって決まります。
したがって、[〜#〜] a [〜#〜]のビューには、例外がキャッチされた場合にのみ表示され、ユーザーが閉じることができるエラーメッセージビューが含まれています。 (エラーメッセージビューの[OK]ボタンは、[〜#〜] a [〜#〜]でコマンドを呼び出し、[〜#〜 ] a [〜#〜]のErrorプロパティ。これにより、エラーメッセージビューの表示がCollapsed
)に変更されます。
これまでのところ、これは適切なMVVMデカップリングを維持するための優れたアプローチのようです。
お役に立てば幸いです。正直なところ、WPFアプリのSystem.Windows.MessageBox.Show()
は純粋に最後の手段だと思います。なぜその古いものを支持してUIの豊富な制御をあきらめるのですか?そういえば、ここに 別のポップアップ実装アプローチ があります。