この問題にアプローチするには、いくつかの方法があります。
最も簡単なのはMessageBox.Show
、ビュー モデルで使用することです。これは、コーディングが簡単で、理解しやすいものです。また、ビュー モデルを単体テストする能力も損なわれます。これは、その動作がユーザー入力をブロックして待機するためです。
複雑さの連鎖の次のステップは、ビュー モデルがイエスかノーかの質問をする必要があるときに使用するインターフェイスを定義することです。例えば:
public interface IConfirmationDialogService
{
bool Show(string question);
}
次に、ビュー モデルはプロパティを実装します。
public IConfirmationDialogService ConfirmationDialogService { get; set; }
そして、ビュー モデルがアプリケーション内にあるときに使用するサービス クラスを実装します。
public class ViewConfirmationDialogService : IConfirmationDialogService
{
public string Caption { get; set; }
public bool Show(string question)
{
return MessageBox.Show(
string question,
Caption,
MessageBoxButtons.YesNo,
MessageBoxImage.Question) == MessageBoxResult.Yes;
}
}
ビューモデルのどこでも、ユーザーから確認を得ることができます:
if (!ConfirmationDialogService.Show("Do you want to do this?"))
{
return;
}
これをどのように単体テストしますか?嘲笑で。単体テストでは、ユーザー入力をモックするためのクラスを実装します。
public class MockConfirmationDialogService : IConfirmationDialogService
{
public MockConfirmationDialogService(bool result)
{
_Result = result;
}
private bool _Result;
public bool Show(string question)
{
return _Result;
}
}
ユーザー入力を待機するメソッドをテストできるようにします。たとえば、次のようになります。
MyViewModel vm = new MyViewModel()
ConfirmationDialogService = new MockConfirmationDialogService(false);
vm.ExecuteCommand();
Assert.IsFalse(vm.CommandChangedSomething);
vm.ConfirmationDialogService = new MockConfirmationDialogService(true);
vm.ExecuteCommand();
Assert.IsTrue(vm.CommandChangedSomething);
複雑さの次の段階は、これがビュー モデルにダイアログを実装する多くの問題の 1 つに過ぎず、IConfirmationDialogService
yes または no の質問の代わりに、あらゆる種類のダイアログを処理できる、より堅牢なダイアログ サービスが必要です。それまでには、独自のビュー モデル フレームワークを実装する準備が整っているので、既存のビュー モデル フレームワークを調べて、それらがどのように機能するかを確認する必要があります。