4

wpf mvvm アプリの作成を開始しました。ビューモデルの重要な要素は、ビューがビューモデルとやり取りできるようにする疎結合の方法を持つ一連の ICommand であるようです。

私の質問はこれです。メソッドに直接バインドできないのはなぜですか?

ICommand オブジェクトにデリゲートを挿入できる Josh Smith の ICommand の RelayCommand 実装を使用しましたが、実際には、ボタンを押してビューモデルのメソッドを呼び出せるようにする簡単な方法はありますか?

私はMVVMを初めて使用します。啓発が必要だと思います

4

5 に答える 5

7

Button(たとえば) デリゲートを受け入れるプロパティがないため、メソッドに直接バインドすることはできません。代わりに、Commandtype のプロパティがありますICommand。A RelayCommand(aka ) は、デリゲートをラップDelegateCommandする単なる anです。ICommand

ビューがマークアップ拡張機能を介してビューモデルの特定のメソッドにバインドできない技術的な理由はわかりません。

<Button Command="{ViewModelMethod SomeMethodName}"/>

ただし、これは遅くなり、ビューとビュー モデル間の結合が増加します。ビューが type のビュー モデルのプロパティのみを認識している場合、ICommandそのコマンドの実装は、ビューが認識していない状態で完全に変更される (またはメソッドの名前が変更される) 可能性があります。

于 2009-05-29T15:48:23.120 に答える
6

私は完全に同意しません。

呼び出しの速度は関係ありません。コマンドはユーザーとの対話であり、速度を必要としません。

結合に関する議論にも欠陥があります。{Binding MyProperty} は結合していないのに、{ViewMethod MyMethod} は結合しているのはなぜですか?

メソッドをラップするために特別に作成された「コマンド」を必要とするのはばかげています。コマンドは隠れた便利な実装かもしれませんが、C# には既にメソッドがあり、それらを大きくてかさばる何かに置き換えるのは適切ではありません。

MarkupExtension と Binding のことは、本当に難しいです。しかし、それは可能です。実際には、これで完了です。CodePlex の MethodCall プロジェクトを見ることができます: http://methodcallthing.codeplex.com/

バインディングを使用してメソッドに「this」を選択し、バインディングを使用して引数を取得できます。そして、それらはすべてライブです。つまり、コマンドが呼び出されたときに計算されます。もう 1 つのボーナス機能は、メソッド呼び出しの結果のプッシュアウトです。これにもバインディングを使用できます (OneWayToSource)。

于 2009-07-19T00:59:27.127 に答える
5

ICommandは、制御を有効にするために必要なCanExecuteを提供します。単純なデリゲートはそうではありません。ICommandは行く方法です。

于 2009-09-02T23:47:24.380 に答える
3

どうやら Microsoft は Command を一流のものにする必要があったようです。おそらく、ほとんどのアプリケーションで CanExecute が必要だと感じていたからでしょう。CanExecute は、ビューモデルのプロパティにバインドする別の DependencyProperty であるべきだと思いますが、何を知っていますか?

おそらく彼らは、コマンドの実装をコントロールのデータコンテキストから分離する必要があるとも考えていました。OO の基本原則と同様に、ロジックは操作対象のデータの近くに存在する必要があるため、これは不要に思えます。

個人的には、コマンドを実装するために作成しなければならない混乱のため、MVVM でコマンドを使用することは避けています。ビューのコード ビハインド デリゲート イベントをビューモデルに任せるだけです。

于 2010-06-24T21:06:14.133 に答える
1

この質問のタイトルの言い回しが原因で、読者はICommandUI アクションを viewModel のメソッドに直接バインドする方法ではなく、 の代わりを探してここにたどり着くかもしれません。(「CanExecute」部分をどうするかという問題が未解決のままであるため、これはほとんど価値がありません。)

の使用はICommandで定義されているため、それ自体で問題があります。つまり、ViewModel で sWindows.Inputを宣言するには、アプリケーション ロジック内から WPF とキッチン シンクを参照する必要があります。他の多くの GUI 機能が利用可能であるICommandことに気付き、それを利用し始めると、アプリケーション ロジックとプレゼンテーション ロジックが混在するひどい混乱が生じる可能性があります。MessageBox

したがって、 を取り除きたい場合は、using System.Windowsを取り除く必要があり、 をICommand取り除きたい場合はICommand、次のことを知っておくとよいでしょう。

WPF (具体的には XAML デザイナー) では、viewModel がインターフェイスのインスタンスを静的に公開する必要はありません。ICommand

ここで静的とは、設計者が設計時にリフレクションを使用して、コマンド オブジェクトがICommandインターフェイスを実装していることを証明できる必要がないことを意味します。代わりに、WPF は実行時にチェックして、UI アクションが実際に実装されるオブジェクトにバインドされていることを確認しますICommand。

したがって、ビューモデル (アプリケーション ロジック) では、ICommandWPF のインターフェイスの代わりにCommand、独自のデバイスのインターフェイスを使用できます。必要なのは、実行時にインスタンス化してCommandインターフェイスを実装するクラスも実装ICommandすることだけです。 WPFを満足させてください。このようにして、ViewModel 内からのインクルードを回避でき、その後、アプリケーション ロジックでのICommand参照を回避できる場合があります。System.Windows

于 2020-01-06T13:48:31.643 に答える