WPF は、独自のアプリケーションでコマンド バインディングを作成できる定義済みコマンド (ApplicationCommands.Save、NavigationCommands.NextPage など) のライブラリを提供します。単一の RoutedCommand/RoutedUICommand に対して複数のコマンド バインディングを作成し、実行されるさまざまなハンドラーを指定することで、アプリケーションのコンテキストに応じてさまざまな動作を取得できることを私は知っています。
私が理解しているように、RoutedUICommand の主な目的は、共通のセマンティック リファレンスを提供することです。ApplicationCommands.New は、MSDN のドキュメントを引用すると、「新しいアイテムを作成する意図を示します」。このコマンドをコマンド バインディングで使用して、アプリケーション内のいくつかの無関係なフォームに新しい項目を作成できます。
この種の再利用が行われていることはめったにありません。オンラインのコードと私が取り組んだプロジェクトでは、通常、'NewEmailCommand' のような名前のコード ビハインドまたはビューモデルで定義された RoutedCommand が表示されます。
コマンドを再利用することにはいくつかの利点があります。
- 通常、RoutedUICommands には Text プロパティが定義されているため、メニュー項目のヘッダーを定義する必要はありません。
- コマンドに入力ジェスチャが定義されている場合、それが使用されるすべての場所で入力バインディングを指定する必要はありません。
- コマンドに入力ジェスチャが定義されている場合、メニュー項目の InputGestureText が自動的に入力されます。
- 同じコマンドを使用すると、コマンドに使用されるラベルとキー/マウスのバインドの両方で、アプリケーション全体の一貫性が促進されます。
考えられるいくつかの欠点：
- 状況によっては、コマンドがあいまいになることがあります。たとえば、1 つの場所に 2 つの異なる「新規」コマンドが必要な場合があります (New->{Project..., Web Site...})。
- コマンドを再利用する代わりに、静的ハンドラーを使用するコマンド バインディングを再利用したい場合があります。
- ApplicationCommands.New は特に有益なコマンド名ではありません。現在のコマンド ハンドラー (何が作成されているかなど) については何も通知しません。
私はコマンドを再利用する傾向がありますが、前述したように、実際には見たことがありません。
あなたの好みは何ですか？聞いたことのない、受け入れられている「ベスト プラクティス」はありますか? コマンドを再利用することによる明らかな問題/その他の利点はありますか?