MVVMパターンを使用してWPFアプリケーションを作成する場合、最も基本的なイベント処理を開始するために必要なツールを自分で収集する必要があるようです。
現在、ComboBoxでItemSelectedイベントを処理する方法を探しており、これを行うためのトリックと回避策の提案を取得しています（XAMLトリガーを使用するか、選択したアイテムに他の要素をバインドするなど）。わかりました、私はこの道を進むことができます、しかしそれは車輪の再発明であるようです。ViewModelで処理できるItemSelectedコマンドがあると便利です。
私はいくつかの標準ツールのセットが不足していますか、それともWPFでMVVMを実行しているすべての人が、イベントとコマンドを使用して最も単純な配管タスクを実行できるように、基本的に独自のツールのコレクションを構築してまとめていますか？ Click = "eventHandler"で？
コマンドの複雑さについては正しいです。私は MV-VM パターンにできるだけ近づけるようにしていますが、単純なユーザー イベントを処理するためだけに高度な回避策を正当化することはできません。
私の意見では、コードが大幅に簡素化されるのであれば、View でユーザー イベントを処理しても問題ありません。ビューでユーザー イベントを処理する場合、ビューのコード ビハインドはビューモデルのメソッドをすぐに呼び出す必要があります。このように、まだロジックを ViewModel に保持したままで、View に小さな配管コード (イベント ハンドラー) しかありません。MV-VM の純粋主義者がビューのコード ビハインドにコードを含めるべきではないと考えていることは知っていますが、イベント ハンドラーのような単純なボイラープレート コードを許可する方が理にかなっている場合もあります。将来、他の人があなたのコードを読んだり変更したりする必要があるかもしれませんが、DelegateCommand よりもイベント ハンドラーを理解する方がはるかに簡単です。
Josh Smith のMVVMに関する記事によると、2005 年 10 月にJohn Gossman のブログで世界に公開されました。
それから、WPF/MVVM が実際に離陸してコミュニティに受け入れられるまでには、さらに 2 ～ 3 年かかりました。それまでに、MVVM の問題をサポートするために WPF を改造するには遅すぎました。また、WPF が MVVM を作成したと言うので、MVVM をサポートするように WPF を変更するのは逆に思えます。
最後に、WPF を行っているすべての人が MVVM を使用しているわけではないため、API はイベントなどの標準的な使用法をサポートする必要があります。
したがって、あなたの質問に答えるために、はい、現時点では「公式」サポートは DelegateCommands フレームワークのみを提供するため、誰もが独自のツールセットをまとめています。
世の中に出回っているコマンドの実装がやり過ぎだと思っているのは私だけではないと聞いてうれしいです。データ バインディングは当然ながら十分にサポートされているように見えますが、ボタンやそれを継承する要素以外のコマンド バインディングを理解しようと、何週間も頭を悩ませてきました。
この質問を投稿していただきありがとうございます。これからは、ビュー モデル関数へのリダイレクトを使用して、ビュー レイヤー内のすべてのイベントを処理すると思います。これは、Microsoft の XAMLFest 2 日間コースの 1 つで基本的な MVVM を教えた方法だと思います。私には十分です！
MVVMはWPFの後に「発明」されたので、MVVMパズルの大きな部分がWPFフレームワークの一部ではないのはなぜですか。
それだけでなく、MVVM 自体は、現実の世界で証明/実践される前に「パターン」として宣言されました。これは、パターンとは正反対のものです。パターンは通常、さまざまな人々が何年にもわたって使用して成功を収めた後に発見され、文書化されます。
パターンを思いついた一人の男がパターンを作るわけではありません。
VisualStudio 用のこの MVVM プロジェクト テンプレートを見てください。
http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx
このテンプレートを使用すると、ICommand のさまざまなニーズに対応するさまざまな DelegateCommand クラスと、キー バインドに役立つ CommandReference クラスを取得できます。
いいスタートだ…