1

WPFコマンドに関していくつか質問があります。

  1. 確認ダイアログはどこに置くべきですか？コマンドコールバック関数内にそれらを表示する必要がありますか？アプリケーションの一部の領域で、確認を表示するコマンドが必要ない場合はどうなりますか？

  2. 削除可能なアイテムを表示するユーザーコントロールがある場合。コマンドをアプリケーションのビューモデルに含める必要があり、それをアイテムの削除に使用する必要がありますか、それともユーザーコントロール自体にも、ビューモデルの関数を呼び出すコマンドが必要ですか？（注：この操作を実行するために必要な情報を持っているのは、アプリケーションビューモデルだけです）

  3. コマンド内でデータを渡すにはどうすればよいですか？私は主DelegateCommandにを使用しており、グリッドアイテムのコマンドを起動すると、選択したアイテムを渡します。そうしないと、アプリケーションのメインビューモデルがグリッドを見つけて、コマンドをグリッドにハードコードする選択を把握する必要があります。再利用可能にしないでください。

4

3 に答える 3

2

確認ダイアログはどこに置くべきですか？コマンドコールバック関数内にそれらを表示する必要がありますか？アプリケーションの一部の領域で、確認を表示するコマンドが必要ない場合はどうなりますか？

確認ダイアログとメッセージ表示ダイアログはビューです。VMには、何かを表示したり、何かを尋ねたりすることをビューに通知する方法が必要です。次に、ビューは、ビューの表示方法（ステータスバー、ウィンドウ、ポップアップ、音声メッセージなど）を決定する必要があります。

削除可能なアイテムを表示するユーザーコントロールがある場合。コマンドをアプリケーションのビューモデルに含める必要があり、それをアイテムの削除に使用する必要がありますか、それともユーザーコントロール自体にも、ビューモデルの関数を呼び出すコマンドが必要ですか？（注：この操作を実行するために必要な情報を持っているのは、アプリケーションビューモデルだけです）

アイテムコントロールは削除コマンドを発生させる必要があります。VMはコマンドを処理し、何をするかを決定する必要があります（VMには選択されたアイテムのリストがあり、ビューはそのリストにバインドされている必要があります）。

コマンド内でデータを渡すにはどうすればよいですか？私は主にDelegateCommandを使用しており、グリッドアイテムのコマンドを起動したら、選択したアイテムを渡します。そうしないと、アプリケーションのメインビューモデルがグリッドを見つけて、コマンドをハードコードする選択を把握する必要があります。グリッドであり、再利用可能にしないでください。

コマンドにはパラメーターを含めることができます（例：RoutedUICommand）。コマンドbindingは、パラメーターのバインディング式を指定できます。ただし、正しいアプローチは、VMを選択のソースとし、ビューの選択とVMの間に双方向のバインドを行うことです。

于 2012-05-24T17:26:33.723 に答える
2

これのビットは意見とスタイルです。. . これが私のアプローチです：

質問1：

確認を処理するユーティリティ クラスがあり、MVVM Light の軽量メッセージングを使用して、ビュー、確認、およびビューモデル間の通信を処理します。

編集：ポイント1に関するもう少し情報

コマンド内から、「ConfirmDeletionMessage」の行に沿ってメッセージを送信します。これは、ダイアログ ユーティリティ クラスによって取得されます。ダイアログ ユーティリティ クラスは、適切なメッセージをユーザーに表示し、結果を確認します。結果に基づいて、「DeletionConfirmedMessage」または「DeletionCanceledMessage」をブロードキャストし、ViewModel によって処理されて、削除を完了するかキャンセルします。

このメッセージに複数のサブスクライバーがいる場合、それらがどの順序で処理されるかわからないため、リスクが伴いますが、メッセージ コンシューマーを厳密に管理している場合、またはコンシューマで実行できることを確認している場合ランダムな順序で、このアプローチは非常にうまく機能し、ビューとモデルのコードをテスト可能な方法で分離します。

質問2：

これは難しい問題であり、アプリケーション全体に依存します。私は個人的にアイテムのビューモデルに入れるのが好きです。そうすれば、3 番目の質問についてそれほど心配する必要はありません。代わりに、削除アクションは、扱っているアイテムに対して機能するだけです。 ただし、リスト アイテムの外部にあるデータを操作する必要がある場合 (リストから削除するなど)、親ビューモデルにコマンドを配置する方が理にかなっています。

質問 3:

プロパティを使用しCommandParameterます。これを好きなようにバインドできます。

回答＃2への編集

Mark Green (以下にコメントした人) は私に考えさせました。私はもともとこのアプローチを WP7 に採用しましたが、それは私が必要としていたことに完全に適合していました。ただし、絶対に考慮すべき他の方法があります。別のオプションは、ビューモデルで使用できる「確認クラス」です。IoC カーネルを使用している場合、これはコンストラクター/プロパティ インジェクションで簡単に実行できます。または、クラスを取得する他の方法がある場合は、それを行いますが、テストでモックアウトできる方法で行います。次のようになります。

public class ExampleViewmodel : ViewModel
{
      private IConfirmDialogManager _dialogManager;
      public ExampleViewmodel(IConfirmDialogManager dialog)
      {
            _dialogManager = dialog;
      }

      // ... code happens ...
      private void DeleteCommand()
      {
             bool result = _dialogManager.Confirm("Are you sure you want to delete?");
      }
}

次のような IConfirmDialogManager インターフェイスを使用します。

public interface IConfirmDialogManager
{
      bool Confirm(string message);
}

次に、適切に実装します。

于 2012-05-24T16:59:37.543 に答える
1
  1. ビューモデルでダイアログサービスを使用するだけです
  2. 依存しますが、コマンドが配置されているオブジェクト/ビューモデルには、RelativeSourceバインディングで簡単に到達できます
  3. CommandParameter は一方向です。実際、mvvm を使用すると、必要なすべての情報をビューモデルにバインドする必要があります。したがって、コマンドがあり、リストビューから選択したアイテムが必要な場合は、それをビューモデルにバインドでき、これをコマンドパラメーターとして設定する必要はありません
于 2012-05-25T10:32:36.907 に答える