MVVMでは、ViewModelまたはModelはINotifyPropertyChangedを実装する必要がありますか？

私がこれまでに取り組んだほとんどのMVVMの例にはModel実装 INotifyPropertyChangedがありましたが、Josh SmithのCommandSinkの例で はViewModelが実装されていINotifyPropertyChangedます。

私はまだMVVMの概念を認識的にまとめているので、次の場合はわかりません。

• あなたは配置する必要がありINotifyPropertyChanged得るためのViewModelにCommandSink仕事に
• これは単なる標準の逸脱であり、それは本当に問題ではありません
• あなたは常にモデルを実装する必要があり、INotifyPropertyChangedこれは単なるコードミスからアプリケーションに開発された場合に修正される間違いです

あなたが取り組んできたMVVMプロジェクトに関する他の経験は何ですか？

私はまったく反対だと思います、私はいつもINotifyPropertyChanged自分のViewModelを使用します-のようなかなりWPF固有の機能でモデルを汚染したくないのでINotifyPropertyChanged、それらはViewModelに配置する必要があります。

私は他の人が反対するだろうと確信していますが、それが私の仕事のやり方です。

私はモデルがを実装すべきではないという概念に強く同意しませんINotifyPropertyChanged。このインターフェースはUI固有ではありません。変更を通知するだけです。実際、WPFはこれを頻繁に使用して変更を識別しますが、それがUIインターフェースであることを意味するものではありません。次のコメントと比較します。「タイヤはカーアクセサリーです」。確かにありますが、バイクやバスなども使用しています。要約すると、そのインターフェースをUIのものと見なさないでください。

そうは言っても、モデルが通知を提供する必要があると私が信じているとは限りません。実際、経験則として、必要がない限り、モデルはこのインターフェースを実装すべきではありません。サーバーデータがクライアントアプリにプッシュされないほとんどの場合、モデルは古くなる可能性があります。しかし、金融市場のデータを聞くと、モデルがインターフェースを実装できない理由がわかりません。例として、UIなどの非UIロジックがある場合、特定の値の入札価格または売値を受け取ったときにアラートを発行する（例：電子メールを介して）か、注文を出す場合はどうなりますか？これはクリーンな解決策になる可能性があります。

ただし、物事を達成する方法はいくつかありますが、私は常に単純さを優先し、冗長性を避けることを主張します。

何が良いですか？コレクションのイベントまたはビューモデルのプロパティ変更を定義し、それをモデルに伝達するか、ビューに（ビューモデルを通じて）本質的にモデルを更新させるか？

肝心なのは、「これができない、またはできない」と誰かが言っているのを見るときはいつでも、彼らが何を話しているのか分からないという兆候です。

それは本当にあなたのケースに依存し、実際にMVVMは多くの問題を抱えたフレームワークであり、MVVMの一般的な実装全体をまだ見ていません。

MVVMの多くのフレーバーと一般的な問題のいくつかの解決策を説明する時間がもっとあればいいと思います-ほとんどが他の開発者によって提供されますが、私は別の機会にそれをしなければならないでしょう。

MV-VMでは、常にViewModel（モデルは常にではない）が実装されます INotifyPropertyChanged

http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspxからMV-VMプロジェクトテンプレート/ツールキットを確認してください。それはDelegateCommandコマンドを使用し、MV-VMプロジェクトの優れた開始テンプレートになるはずです。

MVVMの名前は非常に貧弱で、ViewModelをViewModelと呼ぶと、適切に設計されたアーキテクチャの重要な機能の多くを見逃してしまいます。

View-ModelをDataControllerのようなものと考え、DataControllerがデータに触れる唯一のアイテムであるアーキテクチャを実装する場合、データに直接触れることはなく、常にDataControllerを使用します。DataControllerはUIに役立ちますが、必ずしもUIだけに役立つわけではありません。ビジネスレイヤー、UIレイヤーなどのためのものです。

DataModel -------- DataController ------ View
                  /
Business --------/

このようなモデルになります。ビジネスでさえ、ViewModelを使用してデータに触れるだけです。その後、あなたの難問はちょうど消えます。

モデルの実装方法によって異なります。私の会社はLhotkaのCSLAオブジェクトと同様のビジネスオブジェクトを使用しており、INotifyPropertyChangedおり、ビジネスモデル全体でています。

私たちの検証エンジンは、このメカニズムによってプロパティが変更されたことが通知されることに大きく依存しており、非常にうまく機能します。明らかに、変更の通知が操作にとってそれほど重要ではないビジネスオブジェクト以外の別の実装を使用している場合は、ビジネスモデルの変更を検出するための他の方法が考えられます。

必要に応じてモデルからの変更を伝播するビューモデルもありますが、ビューモデル自体は、基になるモデルの変更をリッスンしています。

私はパウロの答えに同意します、INotifyPropertyChangedモデルでの実装は完全に受け入れ可能であり、マイクロソフトによって提案さえされています-

通常、モデルは、ビューへのバインドを容易にする機能を実装しています。これは通常、INotifyPropertyChangedおよび INotifyCollectionChangedインターフェースを介してプロパティとコレクションの変更通知をサポートすることを意味します。オブジェクトのコレクションを表すモデルクラスは、通常、ObservableCollection<T>クラスの派生 クラスであり、INotifyCollectionChangedインターフェイスの実装を提供し ます。

そのタイプの実装が必要かどうかを決めるのはあなた次第ですが、覚えておいてください-

モデルクラスが必要なインターフェイスを実装していない場合はどうなりますか？

時には、あなたは実装していないモデルのオブジェクトを操作する必要がありますINotifyPropertyChanged、INotifyCollectionChanged、 IDataErrorInfo、またはINotifyDataErrorInfoインタフェースを。そのような場合、ビューモデルはモデルオブジェクトをラップし、必要なプロパティをビューに公開する必要がある場合があります。これらのプロパティの値は、モデルオブジェクトから直接提供されます。ビューモデルは、公開するプロパティに必要なインターフェイスを実装するため、ビューは簡単にデータにバインドできます。

取得元-http ://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx

私はINotifyPropertyChangedモデルに実装されていないいくつかのプロジェクトで働いていたため、多くの問題に直面しました。VMでは不要なプロパティの複製が必要であり、同時に、BL / DLに渡す前に、基になるオブジェクトを（更新された値で）更新する必要がありました。

モデルオブジェクトのコレクション（編集可能なグリッドやリストなど）または複雑なモデルを操作する必要がある場合は、特に問題が発生します。モデルオブジェクトは自動的に更新されないため、VMですべて管理する必要があります。

しかし、（このプレゼンテーションリンクテキストのように）モデルがサービスである場合があります。これは、アプリケーションにデータをオンラインで提供し、新しいデータが到着したか、イベントを使用してデータが変更されたという通知を補完する必要があります...

MV-VMを使用したい場合、その答えは非常に明確だと思います。

参照：http : //msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

MVVMパターンでは、ビューはUIとUIロジックをカプセル化し、ビューモデルはプレゼンテーションロジックと状態をカプセル化し、モデルはビジネスロジックとデータをカプセル化します。

「ビューは、データバインディング、コマンド、および変更通知イベントを介してビューモデルと対話します。ビューモデルは、モデルの更新を照会、監視、および調整し、ビューに表示するために必要に応じてデータを変換、検証、および集計します。」

私はあなたのViewModelで言うでしょう。モデルはUIに依存しないため、モデルの一部ではありません。モデルは「ビジネスにとらわれないものすべて」であるべき

モデルがViewModelで明白に公開されている場合、モデルにINPCを実装することができます。しかし、一般に、ViewModelラップモデルは、モデルの複雑さを軽減するための独自のクラスです（これはバインディングには役立ちません）。この場合、INPCはViewModelに実装する必要があります。

私は使用しています INotifyPropertyChangeモデルでインターフェースます。実際、モデルプロパティの変更は、UIまたは外部クライアントによってのみ発生する必要があります。

私はいくつかの利点と欠点に気づきました：

メリット

Notifierはビジネスモデルにあります

1. 駆動されるドメインごとに、それは正しいです。いつ上げるか、いつ上げないかを決める必要があります。

短所

モデルにはプロパティ（数量、レート、コミッション、トータルフリート）があります。Totalfrieghtは、数量、レート、手数料の変更を使用して計算されます。

1. dbから値をロードすると、合計料金計算が3回呼び出されます（数量、レート、手数料）。それは一度であるべきです。

2. レート、数量がビジネスレイヤーで割り当てられている場合、通知機能が再度呼び出されます。

3. これを無効にするオプションが、おそらく基本クラスにあるはずです。ただし、開発者はこれを行うのを忘れる可能性があります。

それはすべてユースケースに依存すると思います。

プロパティのロードを持つ単純なモデルがある場合、INPCを実装することができます。簡単に言うと、このモデルはPOCOのように見えますます。

モデルがより複雑でインタラクティブなモデルドメイン（モデルを参照するモデル、他のモデルのイベントにサブスクライブする）に存在する場合、INPCとしてモデルイベントを実装することは悪夢です。

他のいくつかのモデルと連携する必要があるモデルエンティティの位置に自分を置きます。購読するさまざまなイベントがあります。それらはすべてINPCとして実装されています。あなたが持っているそれらのイベントハンドラを想像してみてください。if節やswitch節の巨大なカスケード。

INPCに関する別の問題。アプリは、実装ではなく抽象化に依存するように設計する必要があります。これは通常、インターフェースを使用して行われます。

同じ抽象化の2つの異なる実装を見てみましょう。

public class ConnectionStateChangedEventArgs : EventArgs
{
    public bool IsConnected {get;set;}
}

interface IConnectionManagerINPC : INotifyPropertyChanged
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    bool IsConnected {get;}
}

interface IConnectionManager
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    event EventHandler<ConnectionStateChangedEventArgs> ConnectionStateChanged;
    bool IsConnected {get;}
}

次に、両方を見てください。IConnectionManagerINPCは何を伝えますか？プロパティの一部が変更される可能性があること。あなたはそれらのうちのどれかを知りません。実際には、IsConnectedのみが変更されるように設計されています。残りは読み取り専用であるためです。

反対に、IConnectionManagerの意図は明確です。「IsConnectedプロパティの値が変更される可能性があることを教えてくれます」。

INotifyPropertyChangeモデルではなくビューモデルでを使用するだけで、

モデルは通常IDataErrorInfo、検証エラーを処理するためにを使用するので、ViewModelをそのままにしておけば、MVVMの道を進むことができます。

ビュー内のオブジェクトの参照が変更されたとします。正しい値を表示するために、更新するすべてのプロパティにどのように通知しますか？OnPropertyChangedすべてのオブジェクトのプロパティについてビューを呼び出すのは、私の見方ではごみです。

だから私がやっていることは、プロパティの値が変更されたときにオブジェクト自体に誰かに通知させることです、そして私の見解ではObject.Property1、Object.Property2などのバインディングを使用しています。このようにして、ビューに現在保持されているオブジェクトを変更したいだけの場合は、それを行いますOnPropertyChanged("Object")。

オブジェクトのロード中の何百もの通知を回避するために、私はロード中にtrueに設定するプライベートブールインジケーターを持っています。これはオブジェクトからチェックされ、OnPropertyChanged何もしません。

通常、ViewModelはを実装しINotifyPropertyChangedます。モデルは何でもかまいません（xmlファイル、データベース、またはオブジェクト）。モデルは、ビューに伝播するビューモデルにデータを渡すために使用されます。

こちらをご覧ください

imho私はviewmodelが実装INotifyPropertyChangeし、モデルが別の「レベル」で通知を使用できると思います。

たとえば、一部のドキュメントサービスとドキュメントオブジェクトでは、viewmodelがリッスンしてビューをクリアして再構築するdocumentChangedイベントがあります。編集ビューモデルでは、ビューをサポートするためにドキュメントのプロパティのpropertychangeがあります。保存時にドキュメントでサービスが多くのことを行う場合（変更日、最終ユーザーなどの更新）、Ipropertychangedイベントのオーバーロードを簡単に取得し、documentchangedで十分です。

ただしINotifyPropertyChange、モデルで使用する場合は、ビューで直接サブスクライブするのではなく、ビューモデルでリレーすることをお勧めします。その場合、モデルでイベントが変更されても、viewmodelを変更するだけで、ビューは変更されません。

ビューにバインドされているすべてのプロパティは、ViewModelにあります。したがって、INotifyPropertyChangedインターフェイスを実装する必要があります。したがって、ビューはすべての変更を取得します。

[MVVM Lightツールキットを使用して、ViewModelBaseを継承させました。]

モデルはビジネスロジックを保持しますが、ビューとは関係ありません。したがって、INotifyPropertyChangedインターフェイスは必要ありません。