MVVMを選ぶ理由とその中核となるメリットは何ですか？
WPFの処理中にMVCまたはMVPでMVVMを使用する理由
これを使用することで得られる追加のメリットは何ですか？
編集：
正直なところ、今日はインタビューがあり、この質問をされました。 INotifyPropertyChanged、ICommand、IValue Convertorのように答えましたが、彼は満足していませんでした。これから私はこの質問をしました
前もって感謝します
Jason Dolingerによる特に便利な video を紹介します。
WinFormsの世界から来て、MVXスタイルパターンを実装することは、価値があるよりも面倒に思えましたが、ここ数年WPFで作業した後、正直言って、これ以上何も考慮しないと言えます。パラダイム全体がそのまま使用できます。
まず、主な利点は、viewとmodelを真に分離できることです。つまり、モデルを変更する必要がある場合や、モデルを変更する必要がある場合は、ビューを必要とせずに変更できます。逆も同様です。
次に、modelにはviewに必要なすべてのデータが含まれている可能性がありますが、modelがサポートしていない方法でデータを抽象化したい場合があります。 。たとえば、モデルに日付プロパティが含まれているとします。モデルではDateTimeオブジェクトとしてのみ存在できますが、ビューでは完全に異なる方法でそれを表示したい場合があります。 viewmodelがなければ、ビューをサポートするためにmodelのプロパティを複製するか、 'モデル'を深刻に難読化する可能性があるプロパティを変更する必要があります。
viewmodelを使用して、別個のクラス/ライブラリに存在するモデルの部分を集約し、viewが扱うより滑らかなインターフェイスを促進することもできます。 veryは、ユーザーがデータを表示したい、または表示したいのと同じ方法でコード内のデータを操作することはほとんどありません。それら。
それに加えて、viewとviewmodel間の自動双方向データバインディングがサポートされます。
本当にたくさんの追加機能がありますが、Jasonはそれがfarのほうがいいと言っているので、私のアドバイスはビデオを見ることです。このように数日間作業した後、これなしでどうやって成功したのか不思議に思うでしょう。
幸運を。
これらはMVVMに固有のものです
- ビューの「ブレンド性」が向上します（Expression Blendを使用してビューをデザインする機能）。これにより、幸運なことに、デザイナーとプログラマーがいるチームでの責任の分離が可能になり、それぞれが互いに独立して作業できます。
- "ルックレス"ビューロジック。ビューは、背後で実行されるコードに依存しないため、同じビューロジックを複数のビューで再利用したり、ビューを簡単に再構築または置換したりできます。 「行動」と「スタイル」の間の懸念を分離します。
- ビューを更新するための重複するコードはありません。コードビハインドでは、 "myLabel.Text = newValue"への呼び出しが随所に散りばめられています。 MVVMを使用すると、基になるプロパティとそのすべてのビューの副作用を設定するだけで、ビューが適切に更新されます。
- テスト容易性。ロジックはビューに完全に依存しないため（ "myLabel.Text"参照はありません）、単体テストが簡単になります。ビューに関係なく、ViewModelの動作をテストできます。これにより、コードビハインドを使用してほぼ不可能であるビュー動作のテスト駆動開発も可能になりました。
他の2つのパターンは、それらが対処する懸念の点で、実際には別個のものです。 MVVMをMVPおよびMVCと一緒に使用できます（市販されているほとんどの優れたサンプルが何らかの形でこれを実行しています）。
実際、私の意見では、MVP（監視コントローラーではなくパッシブビューを使用）は、実際にはMVVMの変形にすぎません。
WPFは他のどのUIフレームワークよりも優れたデータバインディングを備えています。
MVVMは単体テスト機能と優れたビュー非依存性を提供するため、使用するのに適しています
ICommandとINotifyPropertyChangedのサポートが強化されていることは、2つの最大の利点です。 MVVMを使用すると、コマンドとデータをWPF UIに簡単に接続できます。物事はうまくいきます。
私は個人的にMVVMを利点としてではなく、WPFのクールな機能を使用したい人のための義務として見ています。
WPFは、UIをモデルから分離できるように、コアにデータバインディングを使用して非常に大きく構築されています。ただし、WPFでデータバインディングを技術的に行う方法は、次のようなクラスに関連付けられているため、多少特殊です。
- DependencyProperty
- INotifyPropertyChanged
- ObservableCollection
このため、標準の.NETテクノロジを使用して希望どおりにモデルを作成することはできません。たとえば、WPF TreeViewでは、データバインディングとテンプレートを使用してw/oを使用することはほとんど不可能です。たとえば、Winformsの一般的なモデルのように単純にデータを設定することはできません。 must ObservableCollectionを使用して階層モデルにバインドし、ノードの子を表す。
したがって、VがXAMLコードを表し、それがコードビハインドの対応物である（つまり、テクノロジとしてWPFに関連付けられている）とし、Mがモデルを表す（とにかく、WPF UIテクノロジに関連付けられていない）とします。
まあ、これらのVとMだけでWPFの下でこれが正しく機能することは決してありません。
あなた必須 2つの間に何かを追加します。 WPFと互換性があり、モデルを理解するもの。 DependencyProperty、ObservableCollection、INotifyPropertyChangedを話すもの。それがVMと呼ばれるものです。
ちなみに、MVVMの代わりに、VとM（w/o VM plumbing））の組み合わせを作成することもできます。MはWPF互換ですが、UIの独立性は妥当です。歴史的に、ObservableCollection WindowsBase.dllアセンブリ（WPFに同梱）にあったため、汎用モデルをUIテクノロジに関連付けられたものにバインドするのは奇妙に見えました。それ以降、System.dllに戻されました。それでも、時々、純粋にVM WPFのために特にMを調整しないモデルを維持...
データバインドに対するXAMLコードの機能、およびトリガーの存在により、MVPおよびMVCパターンが壊れます。