WPFのMVVM-ViewModelにモデルの変更を警告する方法...または私は？

私はMVVMの記事をいくつか読んでいます。主にこれとこれです。

私の具体的な質問は次のとおりです。モデルの変更をモデルからビューモデルに伝えるにはどうすればよいですか。

ジョシュの記事では、彼がそうしているとは思えません。ViewModelは常にモデルにプロパティを要求します。レイチェルの例では、彼女はモデルを実装INotifyPropertyChangedし、モデルからイベントを発生させていますが、それらはビュー自体が使用するためのものです（これを行う理由の詳細については、記事/コードを参照してください）。

モデルがモデルのプロパティの変更をViewModelに警告する例はどこにもありません。これはおそらくそれが何らかの理由で行われていないのではないかと心配しています。 モデルの変更をViewModelに通知するパターンはありますか？ （1）各モデルに1つ以上のViewModelがあると考えられ、（2）ViewModelが1つしかなくても、モデルに対するアクションによって他のプロパティが変更される可能性があるため、このようにする必要があります。

「なぜあなたはそれをしたいのですか？」という形式の回答/コメントがあるのではないかと思います。コメントなので、これが私のプログラムの説明です。私はMVVMを使い始めたばかりなので、おそらく設計全体に問題があります。簡単に説明します。

私は「顧客」や「製品」クラスよりも（少なくとも、私にとっては）興味深いものをプログラミングしています。私はBlackJackをプログラミングしています。

背後にコードがなく、ViewModelのプロパティとコマンドへのバインドに依存しているビューがあります（Josh Smithの記事を参照）。

良くも悪くも、私はモデルのようなだけではないクラスが含まれている必要があることを態度を取ったPlayingCard、Deckだけでなく、BlackJackGameゲーム全体の状態を維持し、そしてプレイヤーがなくなっバストを持っている場合、ディーラーがカードを引くために持って知っているクラス、およびプレーヤーとディーラーの現在のスコア（21未満、21、バストなど）。

BlackJackGame私は「DrawCard」のようなメソッドを公開し、それがいることを私に発生したカードは、以下のような、プロパティを描画する際CardScore、およびIsBust更新されるべきであると、これらの新しい値はViewModelにに伝達。おそらくそれは間違った考えですか？

ViewModelがDrawCard()メソッドを呼び出したという態度を取ることができるので、更新されたスコアを要求し、バストであるかどうかを確認する必要があります。意見？

私のViewModelには、トランプの実際の画像（スーツ、ランクに基づく）を取得してビューで使用できるようにするロジックがあります。モデルはこれに関係するべきではありません（おそらく他のViewModelはトランプ画像の代わりに数字を使用するだけです）もちろん、モデルによってはBlackJackゲームの概念さえも持つべきではなく、ViewModelで処理する必要があると言う人もいるでしょう。

モデルがViewModelに変更を通知するようにしたい場合は、モデルにINotifyPropertyChangedを実装し、ViewModelがサブスクライブしてPropertyChange通知を受け取る必要があります。

コードは次のようになります。

// Attach EventHandler
PlayerModel.PropertyChanged += PlayerModel_PropertyChanged;

...

// When property gets changed in the Model, raise the PropertyChanged 
// event of the ViewModel copy of the property
PlayerModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
    if (e.PropertyName == "SomeProperty")
        RaisePropertyChanged("ViewModelCopyOfSomeProperty");
}

ただし、これは通常、複数のオブジェクトがモデルのデータを変更する場合にのみ必要ですが、通常はそうではありません。

実際にModelChangedイベントをアタッチするためのModelプロパティへの参照がない場合は、Prism EventAggregatorやMVVM Light などのメッセージングシステムを使用できますMessenger。

私が持っているシステムメッセージングの簡単な概要が任意のオブジェクトがメッセージをブロードキャストすることができ、それを要約すると、任意のオブジェクトは、特定のメッセージをリッスンするために購読することができ、私のブログ上を。したがってPlayerScoreHasChangedMessage、あるオブジェクトからをブロードキャストし、別のオブジェクトがサブスクライブして、これらのタイプのメッセージをリッスンし、メッセージをPlayerScore聞いたときにそのプロパティを更新できます。

しかし、これはあなたが説明したシステムには必要ないと思います。

理想的なMVVMの世界では、アプリケーションはViewModelで構成されており、モデルはアプリケーションの構築に使用される単なるブロックです。通常はデータのみが含まれるため、DrawCard()（ViewModelにある）などのメソッドはありません。

したがって、おそらく次のようなプレーンなモデルデータオブジェクトがあるはずです。

class CardModel
{
    int Score;
    SuitEnum Suit;
    CardEnum CardValue;
}

class PlayerModel 
{
    ObservableCollection<Card> FaceUpCards;
    ObservableCollection<Card> FaceDownCards;
    int CurrentScore;

    bool IsBust
    {
        get
        {
            return Score > 21;
        }
    }
}

そしてあなたはのようなViewModelオブジェクトを持っているでしょう

public class GameViewModel
{
    ObservableCollection<CardModel> Deck;
    PlayerModel Dealer;
    PlayerModel Player;

    ICommand DrawCardCommand;

    void DrawCard(Player currentPlayer)
    {
        var nextCard = Deck.First();
        currentPlayer.FaceUpCards.Add(nextCard);

        if (currentPlayer.IsBust)
            // Process next player turn

        Deck.Remove(nextCard);
    }
}

（上記のオブジェクトはすべてを実装する必要がありますがINotifyPropertyChanged、簡単にするために省略しています）

短い答え：詳細によって異なります。

あなたの例では、モデルは「自分で」更新されており、これらの変更はもちろん何らかの形でビューに伝播する必要があります。ビューはビューモデルに直接アクセスすることしかできないため、モデルはこれらの変更を対応するビューモデルに伝達する必要があります。もちろんINotifyPropertyChanged、そのための確立されたメカニズムはです。つまり、次のようなワークフローが得られます。

1. ビューモデルが作成され、モデルをラップします
2. ViewmodelがモデルのPropertyChangedイベントをサブスクライブします
3. ビューモデルはビューとして設定されDataContext、プロパティはバインドされます
4. ビューはビューモデルのアクションをトリガーします
5. Viewmodelはモデルのメソッドを呼び出します
6. モデルは自身を更新します
7. Viewmodelはモデルを処理しPropertyChanged、それPropertyChangedに応じて自身を発生させます
8. ビューはバインディングの変更を反映し、フィードバックループを閉じます

一方、モデルにビジネスロジックがほとんど（またはまったく）含まれていない場合、またはその他の理由（トランザクション機能を取得するなど）により、各ビューモデルがラップされたモデルを「所有」することを決定した場合、モデルへのすべての変更が通過します。ビューモデルなので、そのような配置は必要ありません。

このような設計については、MVVMの別の質問で説明します。

あなたの選択：

• INotifyPropertyChangedを実装する
• イベント
• プロキシマニピュレータを備えたPOCO

私が見ているように、INotifyPropertyChangedは.Netの基本的な部分です。つまり、その中System.dll。「モデル」に実装することは、イベント構造を実装することに似ています。

純粋なPOCOが必要な場合は、プロキシ/サービスを介してオブジェクトを効果的に操作する必要があり、プロキシをリッスンすることによってViewModelに変更が通知されます。

個人的には、INotifyPropertyChangedを大まかに実装してから、FODYを使用してダーティな作業を行っています。POCOの見た目と感じです。

例（ILにFODYを使用してPropertyChangedレイザーを織り込みます）：

public class NearlyPOCO: INotifyPropertyChanged
{
     public string ValueA {get;set;}
     public string ValueB {get;set;}

     public event PropertyChangedEventHandler PropertyChanged;
}

次に、ViewModelにPropertyChangedの変更をリッスンさせることができます。またはプロパティ固有の変更。

INotifyPropertyChangedルートの優れた点は、Extended ObservableCollectionを使用してチェーン化することです。したがって、近くのpocoオブジェクトをコレクションにダンプし、コレクションを聴きます...何かが変わった場合、どこでも、それについて学びます。

私は正直に言うと、これは「コンパイラーによってINotifyPropertyChangedが自動的に処理されなかった理由」の議論に加わることができます。つまり、デフォルトでINotifyPropertyChangedを実装します。しかし、そうではなく、最小限の労力を必要とする最良のルートは、ILウィービング（具体的にはFODY）を使用することです。

かなり古いスレッドですが、何度も検索した後、私は自分のソリューションを思いつきました：A PropertyChangedProxy

このクラスを使用すると、他のユーザーのNotifyPropertyChangedに簡単に登録し、登録されたプロパティに対して呼び出された場合に適切なアクションを実行できます。

独自に変更できるモデルプロパティ「Status」があり、ビューにも通知されるように、その「Status」プロパティで独自のPropertyChangedを起動するようにViewModelに自動的に通知する必要がある場合の例を以下に示します。 ）

public class MyModel : INotifyPropertyChanged
{
    private string _status;
    public string Status
    {
        get { return _status; }
        set { _status = value; OnPropertyChanged(); }
    }

    // Default INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        var handler = PropertyChanged;
        if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class MyViewModel : INotifyPropertyChanged
{
    public string Status
    {
        get { return _model.Status; }
    }

    private PropertyChangedProxy<MyModel, string> _statusPropertyChangedProxy;
    private MyModel _model;
    public MyViewModel(MyModel model)
    {
        _model = model;
        _statusPropertyChangedProxy = new PropertyChangedProxy<MyModel, string>(
            _model, myModel => myModel.Status, s => OnPropertyChanged("Status")
        );
    }

    // Default INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        var handler = PropertyChanged;
        if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

そしてここにクラス自体があります：

/// <summary>
/// Proxy class to easily take actions when a specific property in the "source" changed
/// </summary>
/// Last updated: 20.01.2015
/// <typeparam name="TSource">Type of the source</typeparam>
/// <typeparam name="TPropType">Type of the property</typeparam>
public class PropertyChangedProxy<TSource, TPropType> where TSource : INotifyPropertyChanged
{
    private readonly Func<TSource, TPropType> _getValueFunc;
    private readonly TSource _source;
    private readonly Action<TPropType> _onPropertyChanged;
    private readonly string _modelPropertyname;

    /// <summary>
    /// Constructor for a property changed proxy
    /// </summary>
    /// <param name="source">The source object to listen for property changes</param>
    /// <param name="selectorExpression">Expression to the property of the source</param>
    /// <param name="onPropertyChanged">Action to take when a property changed was fired</param>
    public PropertyChangedProxy(TSource source, Expression<Func<TSource, TPropType>> selectorExpression, Action<TPropType> onPropertyChanged)
    {
        _source = source;
        _onPropertyChanged = onPropertyChanged;
        // Property "getter" to get the value
        _getValueFunc = selectorExpression.Compile();
        // Name of the property
        var body = (MemberExpression)selectorExpression.Body;
        _modelPropertyname = body.Member.Name;
        // Changed event
        _source.PropertyChanged += SourcePropertyChanged;
    }

    private void SourcePropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == _modelPropertyname)
        {
            _onPropertyChanged(_getValueFunc(_source));
        }
    }
}

この記事は役に立ちました：http : //social.msdn.microsoft.com/Forums/vstudio/en-US/3eb70678-c216-414f-a4a5-e1e3e557bb95/mvvm-businesslogic-is-part-of-the-?forum = wpf

私の要約：

MVVM編成の背後にある考え方は、ビューとモデルをより簡単に再利用できるようにすることと、分離されたテストを可能にすることです。ビューモデルはビューエンティティを表すモデルであり、モデルはビジネスエンティティを表します。

後でポーカーゲームを作りたい場合はどうしますか？UIの多くは再利用可能でなければなりません。ゲームロジックがビューモデルにバインドされている場合、ビューモデルを再プログラムせずにこれらの要素を再利用することは非常に困難です。ユーザーインターフェイスを変更したい場合はどうしますか？ゲームロジックがビューモデルロジックに結合されている場合、ゲームがまだ機能していることを再確認する必要があります。デスクトップとWebアプリを作成したい場合はどうでしょうか？ビューモデルにゲームロジックが含まれている場合、アプリケーションロジックは必然的にビューモデルのビジネスロジックと結び付けられるため、これら2つのアプリケーションを並べて維持しようとすると複雑になります。

データ変更通知とデータ検証は、すべてのレイヤー（ビュー、ビューモデル、モデル）で行われます。

モデルには、データ表現（エンティティ）とそれらのエンティティに固有のビジネスロジックが含まれています。カードのデッキは、固有の特性を持つ論理的な「もの」です。優れたデッキでは、重複したカードを入れることはできません。トップカードを取得する方法を公開する必要があります。それが残したよりも多くのカードを配らないことを知る必要があります。このようなデッキの動作は、カードのデッキに固有であるため、モデルの一部です。ディーラーモデル、プレーヤーモデル、ハンドモデルなどもあります。これらのモデルは相互に作用することができます。

ビューモデルは、プレゼンテーションとアプリケーションロジックで構成されます。ゲームの表示に関連するすべての作業は、ゲームのロジックとは別です。これには、画像としての手の表示、ディーラーモデルへのカードの要求、ユーザーの表示設定などが含まれます。

記事の要点：

基本的に、私がこれを説明したいのは、ビジネスロジックとエンティティがモデルを構成するということです。これは特定のアプリケーションが使用しているものですが、多くのアプリケーションで共有できます。

ビューはプレゼンテーション層です-ユーザーと実際に直接インターフェースすることに関連するもの。

ViewModelは基本的に、2つをリンクするアプリケーションに固有の「接着剤」です。

ここに、それらがどのようにインターフェースするかを示す素敵な図があります：

http://reedcopsey.com/2010/01/06/better-user-and-developer-experiences-from-windows-forms-to-wpf-with-mvvm-part-7-mvvm/

あなたの場合-いくつかの詳細に取り組みましょう...

検証：通常、これには2つの形式があります。ユーザー入力に関連する検証は、ViewModel（主に）とViewで行われます（つまり、テキストが入力されないようにする "Numeric" TextBoxがビューで処理されます）。そのため、ユーザーからの入力の検証は通常、VMの問題です。そうは言っても、検証の2番目の「レイヤー」があることがよくあります。これは、使用されているデータがビジネスルールに一致することの検証です。多くの場合、これはモデル自体の一部です。データをモデルにプッシュすると、検証エラーが発生する可能性があります。その後、VMはこの情報をビューに再マッピングする必要があります。

「DBへの書き込み、電子メールの送信など、ビューのない舞台裏での」操作：これは、実際には図の「ドメイン固有の操作」の一部であり、純粋にモデルの一部です。これは、アプリケーションを介して公開しようとしているものです。ViewModelは、この情報を公開するためのブリッジとして機能しますが、操作は純粋なモデルです。

ViewModelの操作：ViewModelにはINPCだけでなく、設定（ユーザーステートなど）の保存など、アプリケーション（ビジネスロジックではない）に固有の操作も必要です。これはアプリによって異なります。アプリによって、同じ「モデル」をインターフェースする場合でも。

それについて考える良い方法-あなたが注文システムの2つのバージョンを作りたいとしましょう。1つ目はWPFで、2つ目はWebインターフェイスです。

注文自体（メールの送信、DBへの入力など）を処理する共有ロジックがモデルです。アプリケーションはこれらの操作とデータをユーザーに公開していますが、2つの方法でそれを行っています。

WPFアプリケーションでは、ユーザーインターフェース（ビューアが操作するもの）は「ビュー」です。Webアプリケーションでは、これは基本的に（少なくとも最終的には）クライアントでJavaScript + HTML + CSSに変換されるコードです。

ViewModelは、使用している特定のビューテクノロジー/レイヤーで機能させるために、モデル（順序に関連するこれらの操作）を適応させるために必要な残りの「接着剤」です。

INotifyPropertyChangedおよびINotifyCollectionChangedに基づく通知は、まさに必要なものです。プロパティの変更のサブスクリプション、プロパティ名のコンパイル時の検証、メモリリークの回避で人生を簡素化するには、ジョシュスミスのMVVM FoundationのPropertyObserverを使用することをお勧めします。このプロジェクトはオープンソースなので、ソースからそのクラスだけをプロジェクトに追加できます。

理解するには、PropertyObserverの使用方法についての記事をご覧ください。

また、Reactive Extensions（Rx）も詳しく見てください。モデルからIObserver <T>を公開し、ビューモデルでサブスクライブすることができます。

男たちはこれに答える素晴らしい仕事をしましたが、このような状況では、MVVMパターンは苦痛だと本当に感じているので、監視コントローラーまたはパッシブビューのアプローチを使用して、少なくともモデルオブジェクトのバインディングシステムを手放しました自分で変更を生成します。

2008年のMVVM記事の「変更のフロー」セクションでわかるように、私は長い間、方向性のあるモデル->モデルの表示->変更のフローの表示を推奨してきました。これにはINotifyPropertyChanged、モデルへの実装が必要です。私の知る限りでは、それが一般的な習慣になってからです。

Josh Smithについて言及したので、彼のPropertyChangedクラスを見てください。これは、モデルのINotifyPropertyChanged.PropertyChangedイベントをサブスクライブするためのヘルパークラスです。

最近、PropertiesUpdaterクラスを作成して、このアプローチをさらに進めることができます。ビューモデルのプロパティは、モデルの1つ以上のプロパティを含む複雑な式として計算されます。

Model内でINotifyPropertyChangedを実装し、ViewModel内でそれをリッスンすることは何の問題もありません。実際、XAMLでモデルのプロパティに直接ドットを入れることもできます：{Binding Model.ModelProperty}

依存する/計算された読み取り専用プロパティについては、これより優れたシンプルなものはこれまで見たことがありません：https : //github.com/StephenCleary/CalculatedProperties。非常にシンプルですが、信じられないほど便利です。それは本当に「MVVMのExcel数式」です。Excelが数式セルに変更を伝達するのと同じように機能し、余計な手間がかかりません。

ビューモデルがサブスクライブする必要があるモデルからイベントを発生させることができます。

たとえば、最近ツリービューを生成する必要があるプロジェクトに取り組みました（当然、モデルには階層的な性質がありました）。モデルでは、私は、ChildElements。

ビューモデルでは、オブジェクトへの参照をモデルに格納しCollectionChanged、次のように、observablecollection のイベントをサブスクライブしましたModelObject.ChildElements.CollectionChanged += new CollectionChangedEventHandler(insert function reference here)。...

次に、モデルで変更が発生すると、ビューモデルに自動的に通知されます。を使用して同じ概念に従うことができPropertyChangedますが、それを機能させるには、モデルからプロパティ変更イベントを明示的に発生させる必要があります。

これは本当に重要な質問のように思えます-それを行うように圧力がない場合でも。TreeViewを含むテストプロジェクトに取り組んでいます。削除などのコマンドにマップされているメニュー項目などがあります。現在、ビューモデル内からモデルとビューモデルの両方を更新しています。

例えば、

public void DeleteItemExecute ()
{
    DesignObjectViewModel node = this.SelectedNode;    // Action is on selected item
    DocStructureManagement.DeleteNode(node.DesignObject); // Remove from application
    node.Remove();                                // Remove from view model
    Controller.UpdateDocument();                  // Signal document has changed
}

これは単純ですが、非常に基本的な欠陥があるようです。典型的な単体テストでは、コマンドを実行してから、ビューモデルで結果を確認します。ただし、2つが同時に更新されるため、モデルの更新が正しいかどうかはテストされません。

したがって、モデルの更新によってビューモデルの更新がトリガーされるようにするには、PropertyObserverのような手法を使用する方がよいでしょう。同じユニットテストは、両方のアクションが成功した場合にのみ機能するようになりました。

これは潜在的な答えではない、と私は理解していますが、それを提示する価値があるようです。