0

子ウィンドウを作成し、ビューモデルからの結果を処理する必要があるとします。

これには、コード ビハインドを使用できます。

例：

// Code Behind
class SampleView : ISampleView
{
  public void CreateChildWindow(params string [] args)
  {
      var childWIndow = ChildViewFactory.Create(args);
      childWindow.Closed += 
      () =>  {
                if(childWindow.Result)
                {
                    this.ViewModel.DoSomething();
                }
                else
                {
                    this.ViewModel.DoSomethingElse();
                }
             };
      childWindow.Show();
  }
}

// ViewModel
class SampleViewModel
{
     private void OnSomeCommandHandler()
     {
         ((ISampleView)this.View).CreateChildWindow(new []{""});
     }

     public void DoSomething()
     {

     }

     public void DoSomethingElse()
     {

     }
}

このアプローチはどこにも見たことがありませんが、かなり論理的であるようです。

それ以来、私は疑問に思っていました-このパターンを使用して考えられる欠点は何ですか?

4

1 に答える 1

1

ここでかなり主観的な質問をしました。筋金入りの MVVM 開発者は、コード ビハインド ファイルを決して使用すべきではないと言うかもしれませんが、他の開発者は、これはまったく問題ないと言うかもしれません。

コードをビューから分離する主な理由は、すべてのビュー モデル コードをモック データ アクセス クラスで簡単にテストできるようにするためです。この分離により、同じコンテンツの異なるビューを交換することもできると言う人もいますが、私はこれを行う必要はありません.

ビューモデルからビューを開くべきではないと言う人がいると思います.ビューモデルはビューについて何も知らないはずです. これらの人々は、ある種のサービス レイヤーを使用して、ビュー モデルから (間接的に) ビューを起動します。他の人は、親ビューのコードビハインドから子ビューを起動することがまさにあなたがすべきことだと言うでしょう。

結局のところ、これは実際には、自分と自分が開発しているアプリケーションに何が適しているかについての個人的な決定です。ビューではなくビューモデルをテストするのが一般的であるため (はい、WPF で自動化された UI テストを認識しています)、ビューのコードビハインドを使用しない唯一の理由は、そのコードがテストされないためです (少なくともビューモデルコードと一緒に通常の方法で）。

しかし、子ウィンドウを起動する単純なコードを本当にテストする必要があるのでしょうか? 私の意見では、そうではありません... Microsoft は既にそれをテストしています。あなたの質問に答えるために、子ウィンドウを起動するためにコード ビハインドを使用することのデメリットは、個人の状況によって異なりますが、深刻なデメリットになる可能性は低いと思います。

于 2013-09-11T08:14:40.370 に答える