1

CanExecute()との使用法は理解していますがExecute()、次のシナリオについて疑問に思っています。

public class MyViewModel : NotificationObject
{
    public MyViewModel()
    {
        FooCommand = new DelegateCommand(DoFoo, CanDoFoo);
    }

    public Bar MyBar { get; set; }

    public DelegateCommand FooCommand { get; private set; }

    public Boolean CanDoFoo()
    {
        return (MyBar != null)
    }

    public void DoFoo()
    {
        MyBar.BarFunc(); //Potential for a NullReferenceException
    }
}

基本的に、コンシューマー ビューは DoFoo メソッドを直接呼び出すことを決定し (明らかにICommandインターフェイスの要点を壊します)、NullReferenceException を引き起こす可能性があります。これは少し主観的かもしれませんが、「標準的な」方法で行うことを望んでいます。

私たちは：

  1. if (MyBar != null)最初に NullReferenceException の可能性を防ぎますか?
  2. CanDoFoo()true を返すことを確認して、NullReferenceException の可能性を防ぎますか?
  3. 消費するビューが適切に動作しており、メソッドを呼び出すことができることを既に確認していると仮定しますDoFoo()か?

補足として、私がこれを尋ねた主な理由は、単体テストを書いているときに、誰かが対応Execute()するメソッドを呼び出さずにメソッドを呼び出すことで、ViewModel を壊す可能性があることに気付いたからです。CanExecute()明らかに、単体テストでは、メソッドを実行する前にメソッドを実行できることを確認しますが、ビューを消費するとそれを無視する場合があります。

更新: (シナリオ 2)

この質問の拡張として、DoFoo()例外に関してメソッドが壊れないシナリオを追加したいのですが、論理的に壊れる可能性がありますか?

public class MyViewModel : NotificationObject
{
    public MyViewModel()
    {
        FooCommand = new DelegateCommand(DoFoo, CanDoFoo);
    }

    public Int32 Age { get; set; }

    public DelegateCommand FooCommand { get; private set; }

    public Boolean CanDoFoo()
    {
        return (Age >= 21)
    }

    public void DoFoo()
    {
        ProvideAlcohal(Age);
    }
}

この 2 番目のシナリオは、実際には壊れません (コマンドは正常に処理できます) が、論理的に壊れます。では、呼び出してビジネス ロジックをもう一度検証するCanDoFoo()か、消費するビューが動作していると仮定するか? (これはビジネス ロジックを壊すだけであることを忘れないでください)。

基本的にはこれに要約されます...消費するビューが不正な動作によって足元を撃たれないようにするための予防策を講じていますか?

4

1 に答える 1

5

WPFまたはSilverlightでのコマンド呼び出しの実装はこれを行うため、UIシステムから心配する必要はありません...

しかし、それは公的な方法です。nullをチェックすることは、あなたができる最速のことの1つです。害はなく、guard句なしでnull例外をスローするため、はるかに安全です。

意味的にCanExecuteは、nullチェックとは異なる方法で実装される可能性があるため、Executeメソッドでnullチェックを実行するだけで、必ずしもチェックする必要はありませんCanExecute。

于 2011-05-12T20:42:18.770 に答える