私はmsdnについて、MVVMのモデルがObservableCollection<T>,INotifyPropertyChanged、IDataErrorなどのインターフェイスを実装するのが一般的だと読んだことがあります。ModelにObservableCollectionとINotifyPropertyChangedがあるのはなぜですか？
私の質問は、ViewModelレベルではなくモデルレベルで行われる理由です。私は、「純粋な」モデルには通知論理、データとビジネスロジックだけがないと期待します。私の最初の印象は、VMがモデルのプロパティをラップし、通知を処理することです。
モデルでこれらのインターフェイスを実装すると多くの場合実装が容易になることは容易に認められますが、モデルが通知の原因となる理由についての説明を探しています。
INPCは、特にWPFに属するICommandとDependencyObjectとは異なり、コアフレームワークの一部です。サービス層からIQueryableを公開することについても同様の質問がありました。 INPCのように、IQueryableはコアフレームワーククラスです。純粋なモデルを作成するためにそれらのいずれかを使用しないことは過度のことです。
さらに悪化すると重複が発生します（VMラップによってプロパティが公開され、プロパティ変更された通知が追加されます）。
Observable Collectionは、別の獣です。通常、ドメインモデルのコレクションはエンティティリレーションを表します。多くの場合、インスタンス化を制御できません。そこにはトレードオフがあります
アプリケーションによっては、同じデータの複数のビューとViewModelがあるかもしれません。読み込み専用の項目のリストを表示するウィンドウが1つありますが、アイテムを追加、編集、削除することができる別のウィンドウでは、
モデルでObservableCollectionとINotifyPropertyChangedを使用すると、編集可能なView/ViewModelで行われた変更は、編集不可能なView/ViewModelで表示および更新されます。
さらに、編集不可能なビューが十分に単純な場合、モデルに直接公開して直接バインドすることも可能であり、受け入れられる可能性があります。通知を処理するViewModelがないため、モデルはジョブ自体を行う必要があります。