MVVMの概念を理解しようとして、私はすでにいくつかのブログを読み、いくつかのプロジェクトを見てきました。
私が理解していることから、ビューはばかげている、それはそれに渡される何かを提示する方法を知っているだけです。
モデルは単なるデータであり、ViewModelは、2つの間のパディングのように機能するものであり、モデルから情報を取得してビューに渡し、ビューはそれを表示する方法を知っている必要があります。または逆に、ビューの情報が変更された場合は、その変更をモデルに渡す必要があります。
しかし、私はまだその概念をどのように適用するのか分かりません。コンセプトを理解できるように、誰かが非常に単純なシナリオを説明できますか？私はすでにいくつかのプロジェクトを見てきましたが、それでも完全には意味がないので、誰かが平易な英語でそれを書き出すことができれば、それは素晴らしいことです。
回答:
私はそれをこのように考えるのが好きです：
あなたが言うように、ビューはばかげています。MVVMに関する独創的で頻繁にリンクされているMSDN記事のライターであるJoshSmithは、ビューは「データが着る服」であると述べています。ビューに実際にデータが含まれたり、データを直接操作したりすることはありません。ビューモデルのプロパティとコマンドにバインドされるだけです。
モデルは、ビジネスオブジェクトと同様に、アプリケーションのドメインをモデル化するオブジェクトです。アプリケーションはミュージックストアですか？おそらく、モデルオブジェクトはアーティスト、アルバム、曲になります。アプリケーションは組織図ブラウザですか？おそらく、モデルオブジェクトはマネージャーと従業員になります。これらのモデルオブジェクトは、いかなる種類のビジュアルレンダリングにも関連しておらず、それらを配置するアプリケーションにも直接関連していません。モデルオブジェクトは、ある種を表すオブジェクトのファミリとして、それ自体で完全に意味をなす必要があります。ドメインの。モデルレイヤーには通常、サービスアクセサーなども含まれます。
これにより、Viewmodelsが表示されます。彼らは何ですか？これらは、GUIアプリケーションをモデル化するオブジェクトです。、つまり、ビューで使用されるデータと機能を提供します。これらは、構築している実際のアプリケーションの構造と動作を定義するものです。モデルオブジェクトの場合、ドメインは選択したドメイン（ミュージックストア、組織図ブラウザーなど）ですが、ビューモデルの場合、ドメインはグラフィカルアプリケーションです。ビューモデルは、アプリケーションが実行するすべての動作とデータをカプセル化します。それらは、オブジェクトやリストをプロパティとして公開するだけでなく、コマンドなども公開します。コマンドは、それを運ぶオブジェクトにラップされた単なる動作（最も単純なメソッド呼び出し）です。ビューは、オブジェクトにビジュアルコントロールをアタッチするデータバインディングによって駆動されるため、このアイデアは重要です。MVVMでは、ボタンにクリックハンドラーメソッドを指定しません。
私にとって、最も紛らわしい点は次のとおりです。
うさぎの穴はさらに深くなります-MVVMを機能させ続けるValueConvertersのように理解すべきイディオムはたくさんあり、ブレンド可能性、テスト、アプリでデータを渡す方法などについて考え始めるときに適用することがたくさんあります。各ビューモデルは必要な動作にアクセスできますが（これが依存性注入の出番です）、うまくいけば上記が良いスタートです。重要なのは、ビジュアル、ドメイン、実際のアプリケーションの構造と動作を3つの異なるものとして考えることです。
この非常に役立つ記事をソースとして使用して、View、ViewModel、およびModelの概要を示します。
ビューは、ウィンドウ、ページ、ユーザーコントロール、データテンプレートなどの視覚要素です。ビューは、ビューに含まれるコントロールとその視覚的なレイアウトおよびスタイルを定義します。
ビューは、そのDataContextプロパティを介してビューモデルを参照します。ビュー内のコントロールは、ビューモデルによって公開されるプロパティとコマンドにバインドされたデータです。
ビューは、ビューとビューモデル間のデータバインディング動作をカスタマイズできます。たとえば、ビューは値コンバーターを使用してUIに表示されるデータをフォーマットしたり、検証ルールを使用して追加の入力データ検証をユーザーに提供したりできます。
ビューは、ビューモデルの状態変化から、またはユーザーのUIとの対話を介してトリガーされる可能性のあるアニメーションや遷移など、UIの視覚的動作を定義および処理します。
ビューのコードビハインドは、XAMLで表現するのが難しい、またはビューで定義された特定のUIコントロールへの直接参照を必要とする視覚的な動作を実装するUIロジックを定義する場合があります。
注：
ビューモデルはビュー内の特定の視覚要素に関する明確な知識を持ってはならないため、ビュー内の視覚要素をプログラムで操作するコードは、ビューのコードビハインドに存在するか、動作にカプセル化されている必要があります。
ビューモデルは非ビジュアルクラスであり、WPFまたはSilverlight基本クラスから派生したものではありません。これは、アプリケーションでユースケースまたはユーザータスクをサポートするために必要なプレゼンテーションロジックをカプセル化します。ビューモデルは、ビューとモデルに関係なくテスト可能です。
ビューモデルは通常、ビューを直接参照しません。ビューがデータバインドできるプロパティとコマンドを実装します。INotifyPropertyChangedおよびINotifyCollectionChangedインターフェイスを介した変更通知イベントを介して、状態の変更をビューに通知します。
ビューモデルは、ビューとモデルの相互作用を調整します。データを変換または操作して、ビューで簡単に使用できるようにしたり、モデルに存在しない可能性のある追加のプロパティを実装したりする場合があります。また、IDataErrorInfoまたはINotifyDataErrorInfoインターフェイスを介してデータ検証を実装する場合もあります。
ビューモデルは、ビューがユーザーに視覚的に表すことができる論理状態を定義する場合があります。
注：
アプリケーションの論理的な動作にとって重要なものはすべて、ビューモデルに入れる必要があります。データバインディングを介してビューに表示されるデータ項目を取得または操作するコードは、ビューモデルに存在する必要があります。
モデルクラスは、アプリケーションのデータとビジネスロジックをカプセル化する非ビジュアルクラスです。彼らは、アプリケーションのデータを管理し、必要なビジネスルールとデータ検証ロジックをカプセル化することによってその一貫性と有効性を確保する責任があります。
モデルクラスは、ビューまたはビューモデルクラスを直接参照せず、それらの実装方法に依存しません。
モデルクラスは通常、INotifyPropertyChangedおよびINotifyCollectionChangedインターフェイスを介してプロパティおよびコレクションの変更通知イベントを提供します。これにより、ビューでデータを簡単にバインドできます。オブジェクトのコレクションを表すモデルクラスは、通常、ObservableCollection<T>クラスから派生します。
モデルクラスは通常、IDataErrorInfoまたはINotifyDataErrorInfoインターフェイスを介してデータ検証とエラーレポートを提供します。
モデルクラスは通常、データアクセスとキャッシュをカプセル化するサービスまたはリポジトリと組み合わせて使用されます。
私はこれをMVVMのこのシリーズで考えることができるように「平易な英語」で書きました。特に、この図はおそらく最も単純で短い説明です。
そうは言っても、基本的に「モデル」はデータまたはビジネスルールです。それがどのように、どこで使用されるのか、特にどのテクノロジーがそれを使用するのかについては、本当に知らないはずです。「モデル」はアプリケーションの中核であり、アプリケーションがWPF、Silverlight、Windowsフォーム、ASP.NETなどであるかどうかを心配する必要はありません。純粋な形式の「それ自体」です。
「ビュー」は、完全にテクノロジー固有の部分です。MVVMでは、理想的には、ビューはほぼ100％XAMLである必要があります。これにより、柔軟性が大幅に向上します。
ただし、モデルからの情報を、手元のテクノロジーで使用できる形式に変換するものが必要です。ここで、ViewModelが機能します。たとえば、これは多くの場合、コマンド（ロジックを実行するため）、実装INotifyPropertyChanged（データバインディングサポートのため）などを含む特定のデータのモデルクラスを「ViewModel」に「ラップ」します。それだけです-モデルを作成するのはブリッジですビューで使用できます。
基になるモデル上で一貫したファサードを提示するViewModelの構築は、見た目よりもはるかに複雑になる可能性があります。ViewModelオブジェクトの構築に関するこの記事では、ViewModelの構築方法を示し、発生する可能性のあるいくつかの問題と、合理的な解決策のように見えるものについて説明します。それを読んだとき、コレクションの扱いに関するセクションがありませんでしたが、それでもいくつかの興味深い点があります。