ちょっと変わった質問ですが、あなたの意見は私にとって非常に興味深いものです。
Command を WPF または Silverlight に実装し、CanExecute が false を返しても、何らかの理由で Execute メソッドが正しくない状態で呼び出されたとします。それがどのように起こったかは問題ではありませんが、そうでした。もちろん、状態が正しくないため、コマンドを正しく実行できませんが、どうすればよいでしょうか。
この状況を無視する必要がありますか? しかし、重大な問題を見逃す可能性があります。
例外をスローする必要がありますか? しかし、私たちは皆非同期の世界に住んでいるので、理論的には、チェックを実行して CanExecute に対して true を返すことができ、状態が正しくない状態に変化し、Execute が正しくない状態で呼び出される可能性があります。したがって、必要に応じてすべてを行いましたが、例外があります。
では、どう思いますか教えてください。
CanExecute は、これが実際に問題になるほど長くて複雑であってはなりません。
Execute を実行する瞬間に CanExecute を再度チェックする (CanExecute で悪いことをしていなければ同期的に行われます) 以外にできることはほとんどありません。ビジネス ルールは、データ リポジトリに向かう途中でビジネス関連の問題をキャッチする必要があり、実行の結果として呼び出されるその他の関数も独自の検証とデータ チェックを行うことができます。
これが発生している場合 は、CanExecute のどこかに問題があることを意味します。または、CanExecute が呼び出されなかった可能性があります (プロパティが変更され、コマンドが再評価されなかった可能性があります)。
この不正なコードの確かな例を挙げない限り、それが私が言えることのほとんどです。
Execute メソッドで CanExecute を呼び出すことは問題ではありませんが、false の場合はどうすればよいでしょうか。終了する必要がありますか？
はい、そのまま終了できます。または、検証関連の例外をスローすることもできます (通常はバインディングを介してこれを呼び出すため、あまりお勧めしません)。基本的に、Execute はチェーンの開始点であり、それを呼び出す人または何かがエラーを処理するように設定する必要があります。呼び出されたという理由だけで成功を期待することはできません。
しかし、同僚が私のコマンドを使用するコンポーネントを作成し、Execute を呼び出す前に CanExecute をチェックするのを忘れた場合はどうなるでしょうか?
これは、ビュー モデルにコマンドを実装してからそれにバインドするのは良くないと言うケースです。コマンドが代わりにビューのコード ビハインドに実装されている場合は、そこからビュー モデルを呼び出して、必要な作業 (データの保存など) を実行し、その呼び出しを try/catch でラップすることができます。例外として、UI に何かを簡単に表示できます (MVVM に正しく準拠している場合、これは VM からは不可能です)。
覚えておいてください: コマンドへのバインドは素晴らしいですが、コマンドがすべてビューモデルにある必要があるとは誰も言いませんでした。データ検証を行うことができるように、CanExecute でさえビューモデルを呼び出すことができます。優れたコーダーであれば、ビューに必要なビューモデルのすべてのメソッド/プロパティがインターフェイスを介して公開されます。