2

WPFでは、カスタムコマンドにcommand_Executedやcommand_CanExecuteなどのイベントハンドラーがあります。ベストプラクティスは、実装ロジックを分離コードクラスに直接実装せず、上位レベルの実装ロジックへの関数呼び出しのみを含めることです。

カスタムコマンドを作成するときに、コマンドのハンドラー関数に関数呼び出しが1つしかない場合は、それをコードビハインドに直接配置するのは簡単ですが、複数の関数呼び出しがある場合、または関数呼び出しがそれに基づいて何かを返す場合はどうなりますかそのうちの決定が行われます（特に、コマンドを無効化/有効化するcommand_CanExecute関数の場合、コマンドをいつ有効化または無効化するかを決定する必要があります）。私が考えていた可能性は次のとおりです。保守性、コードのクリーンな維持、ソフトウェアエンジニアリングの原則、およびベストプラクティスの観点から、どれが最も適切ですか。

  1. すべての関数呼び出しと意思決定ステートメントをコードビハインド（command_executeまたはそのcommand_execute呼び出しのコードビハインドの一部の関数）に保持します。コードが単純であれば問題ありませんが、コードの背後に多くのハンドラーがあると、物事が醜くなります。ここには実装コードはなく、先に述べた意思決定コードのみがあります。

  2. コマンドを定義し、静的プロパティを介してアクセスできるようにするクラスに実装ロジックを保持します。これで、分離コード内のハンドラーは1つの関数呼び出しのみを持ち、必要に応じて戻り値を受け取ります。

  3. アプリケーションの実際の機能を実装する上位レベルのクラスに実装して、分離コードハンドラーが関数呼び出しを1つだけ持つようにします。これは最も理にかなっていますが、コマンドハンドラーが多くの異なる無関係なクラスからメソッドを呼び出さなければならない場合があり、そのロジックをどこに配置するかを決定するのが難しいため、このオプションは私の心に疑問を投げかけます。

  4. 私が逃した他のもの。

4

1 に答える 1

4

通常、私は（MVVMを使用していない場合はコードビハインドで）RelayCommandまたはDelegateCommandを使用しますViewModel

private ICommand _customCommand;

public ICommand CustomCommand
{
    get
    {
        if (_customCommand == null)
        {
            _customCommand = new RelayCommand(
                CustomCommandHandler, CanCustomCommandExecute);
        }
        return _customCommand;
    }
}

private void CustomCommandHandler()
{
    // Execute Command
}

private bool CanCustomCommandExecute()
{
    // Return true/false if the command can execute or not
}

XAML：

<Button Command="{Binding CustomCommand}" />
于 2011-10-17T20:12:53.043 に答える