5

私が理解していることから、コマンドパターンの目標は、UIの相互作用をアプリケーションロジックから分離するのを助けることです。適切に実装されたコマンドを使用して、[印刷]メニュー項目をクリックすると、次のような一連の対話が発生する可能性があります。

(button) ---click executes command----> (command) ---calls Print() in app logic ---> (logic)

これにより、UIをアプリケーションロジックから分離することができます。

私はWPFコマンドを見てきましたが、ほとんどの場合、このパターンがどのように実装されているかがわかります。ただし、ある程度、コマンドパターンが複雑になり、UIをアプリケーションロジックから分離することを思いとどまらせるような方法で実装できたように感じます。

たとえば、テキストボックスにテキストを貼り付けるボタンがあるこの単純なWPFウィンドウについて考えてみます。

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Window.CommandBindings>
        <CommandBinding Command="ApplicationCommands.Paste"
                        Executed="CommandBinding_Executed"/>
    </Window.CommandBindings>
    <StackPanel>
        <TextBox x:Name="txtData" />
        <Button Command="Paste" Content="Paste" />
    </StackPanel>
</Window>

コードビハインドは次のとおりです。

namespace WpfApplication1
{
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void CommandBinding_Executed(object sender, ExecutedRoutedEventArgs e)
        {
            ApplicationCommands.Paste.Execute(null, txtData);
        }
    }
}

コマンドから何を得ましたか？コマンドバインディングイベントハンドラーのコードをボタンのイベントに簡単に配置できたように思えますClick。もちろん、複数のUI要素を[貼り付け]コマンドに関連付けることができ、1つのイベントハンドラーを使用するだけで済みますが、複数の異なるテキストボックスに貼り付けたい場合はどうすればよいですか？イベントハンドラロジックをより複雑にするか、より多くのイベントハンドラを作成する必要があります。だから今、私はこれを持っているように感じます：

(button) ---executes Routed Command---> (Window) ---executes command binding----(command binding)
(logic) <---calls application logic--- (event handler) <-----raises event --------------|

ここで何が欠けていますか？それは私には間接的な余分な層のように見えます。

4

4 に答える 4

3

あなたは概念を混乱させるかもしれません。

ICommandインターフェイスはコマンドパターンをサポートしています。これにより、ユーザーアクションを再利用可能なクラスに抽象化できます。

ICommandルーティングされたコマンドは、ハンドラーのビジュアルツリーを検索する特定の実装です。これらは、多くの異なるコントロールで実装できるコマンドに特に役立ち、現在のコントロールでそれを処理する必要があります。コピー/貼り付けを考えてください。それを処理する可能性のあるコントロールがたくさんある可能性がありますが、routedコマンドを使用することにより、routedコマンドシステムはフォーカスに基づいてコマンドを処理するための正しいコントロールを自動的に見つけます。

于 2009-01-21T19:59:42.800 に答える
2

既に述べたことに加えて、特定の貼り付けの例で忘れていたのは、CommandTarget および CommandParameter プロパティです。貼り付けの場合、CommandTarget として設定することで TextBox を指定できます。

これらのプロパティは、異なるコントロールから同じ RoutedCommand を使用する場合に不可欠です。これらを使用すると、コマンドが呼び出されているコンテキストに関する情報を Executed ハンドラーに提供できます。

于 2009-01-21T22:04:05.857 に答える
2

コントロールを作成するときは、RoutedCommands と RoutedUICommands を使用することをお勧めします。たとえば、TextBox は UndoCommand を実装しており、Input guseture は既にCtrl+にバインドされていZます。ただし、ビュー モデルを構築するときは、Execute と CanExecute の内部実装を備えたカスタム ICommand を好みます。DelegateCommand は Prism でこれを提供します。これにより、ビュー/xaml デザイナーは、使用する正しい Execute/CanExecute ハンドラーではなく、コマンドだけを気にすることができます。これにより、より表現力豊かなビュー モデルが可能になります。

ps。デリゲート コマンドは、InputBinding ではまだ (エレガントに) 機能しません。マイクロソフトの誰かがこれを修正してくれませんか!

于 2009-01-22T10:18:12.537 に答える
0

それらはいくつかの点でやり過ぎかもしれませんが、コマンドが利用できないとき（テキストが選択されていないなど）にボタン/メニュー項目を自動的に有効/無効にできるCanExecuteのようないくつかの素晴らしい利点があります。また、コードを使用せずにBlendでコマンドを実行することもできます。これは、デザイナーに最適です。

于 2009-01-21T19:52:23.783 に答える