私はMVVMパターンを学んでいるので、私は質問をしました。私はサンプルノートアプリケーションを構築しています。このアプリケーションでは、NotesViewでノートのリストを表示できます。 NotesViewのDataContextはNotesModelViewです。モデルのコレクションのMVVMモデル？
私の質問は（NoteModelが含まれています）NoteModelまたはNoteModelViewのコレクションをNotesModelView含まれている必要がありますか？
私は、すべてのモデルクラスをビューモデルにラップする傾向があるので、私の一般的な答えはNoteModelをラップするNoteViewModelのコレクションを持つことです。
でも、私はDRY principleのファンだから、ViewModelが何のメリットも加えていないようなケースでは（例えば、私はデータのフォーマットを変更する必要はなく、変更する必要はない通知と私はビューに生のモデルを公開しても構わない）時々私はこのルールを破る。
MVVMを習得しようとしているので、この特定のケースの私の提案はにあります。ビューモデルのコレクションに行ってください。これにより、MVVMの理解を深めることができ、将来のアプリケーションでこの疑問に直面したときに、これらの区別を後で行うのに役立ちます。
[OK]を、あなたの命名は少し混乱して、私はクリーンな命名基準に選ぶだろう！人々は 'View'を使ってビューの後ろに、そして 'ViewModel'を使ってモデルを見るのが普通です。
は、だからあなたの場合には、そのDataContextのであるNotesViewModelのNotesViewを持っています。 NotesViewModelには、Notes（またはそれを呼び出す場合はNotesModel）のコレクションが必要です。 NotesViewModelにはNotesViewModelのコレクションがありません。これは、NotesデータをNotesViewに表示するだけでよいため、不要です。
混乱している名前を残して申し訳ありませんが、アプリケーションで使用している名前付けスタイルではありません。私はちょうど私がモデルを「モデル」で後固定したかどうかを理解することがより簡単になるだろうと思った。 – Jackson
私は常にビューモデルで自分のモデルをラップします。このようにして、ユーザーが行った変更は、ユーザーが変更をコミットするまで（たとえば、[保存]ボタンを使用して）ビューモデルにのみ適用され、基になるモデルには適用されず、ユーザーがコミットしたくない場合、モデルを変更せずにビューモデルを破棄し、最初から開始します。これは、データベースエンティティ/オブジェクトを扱うときに特に重要です。エンティティに直接加えられた変更は、少なくともロールバックには苦労する可能性があります（少なくともEntity Frameworkを使用している場合は）
「コミット」が暗黙的であり、上記は当てはまりませんが、ビジネスモデルの単体テストも可能なので、ビューモデルを使用するのがよい方法だと私は考えています。 MVVMの主な動機はメンテナンス性であり、優れたユニットテストを実施することがそれを達成する一つの方法です。モデルとして、あなたはノートタイプののObservableCollectionあなたのモデルのリストを表しますリストを定義する必要があります - あなたの例では
ありがとう - 私はこれを考えなかった！ – Jackson
は、あなたは注意が必要です。 このリストはViewModelにあり、プロジェクトの任意のビューにバインドすることができます
アドバイスありがとうございます - 私はまだその険しい学習曲線を登っていますので、私は正しくパターンを理解していますそれから逸脱し始める。 – Jackson
いいえ問題ありません。あなたが助けてくれたすべての回答に投票してください。 –