MVVMでは、Entity Frameworkを使用して、ビューモデルに何が挿入されますか？

Question

私はWPFデスクトップアプリケーションを作成しています。私はMVVMのデータの流れを理解しようとしています。私はデータアクセスとしてEntity Frameworkを使用しています。私は各SQLテーブルを表すPOCOエンティティクラスを持っているので、コードファーストのアプローチを使用しています。

この設定では、私のモデル（MVVMのM）が私のPOCOエンティティクラスであると私は理解しています。私のビュー（MVVMのV）は私のWPFウィンドウです。

ビューモデルには何が挿入されますか？私は私のビューの中で自分のEFクエリを作成し、ビューモデルを作成しますか？私のビューモデルは独自のクエリを実行しますか（おそらく、クラスコンストラクタ内で）？

Answer 1

通常、ビューはWPFウィンドウで、対応するコードの背後にあります。ビューモデルは、特定のビューのデータレイヤ要件を処理し、処理を行うために作成されたシンプルなクラスです。コントロールのXAMLビューでコマンドを使用するのが一般的であり、各コマンドはビューモデルにあるコマンドインスタンスにバインドされています。ビューモデルは、依存性注入によって作成することもできますし、コードビューのビューのコンストラクタに渡すこともでき、コードの背後にメンバー/プロパティとして格納されます。ビュー・データ・コンテキストをビュー・モデルのインスタンスに設定して、ビュー・モデルのプロパティおよびコマンドにバインドできるようにしてください。

this.DataContext = new TheViewModelType(); 

エンティティフレームワークの古いプレーンの古いCLRオブジェクトは、データモデルであり、ビューは通常これらについては認識してはいけません。ビューモデルには、Itemsコントロールなどでビューがバインドできるモデルタイプのプロパティがあります。ビュー中のSO：ビューのDataContextのは、ビューモデル型のインスタンスであるため

<ItemsControl x:Name="CarItems" ItemsSource="{Binding Vm.CarsCollection}"></ItemsControl> 

ので、ビューコントロールは、ビューモデルのプロパティに直接結合することができます。この例は、Carsのコレクションを持つビューモデルであり、ビューモデルはCarsコレクションに必要なときにサービスを呼び出すことができます。明らかにカーがモデルです。例INT車サービスについて

public MyViewModel() 
    { 
     Cars = TheCarsDataLayerService.GetCars(); 
    } 

    private IObservable<Car> _cars; 

    public IObservable<Car> Cars 
    { 
     get { return _cars; } 
     set 
     { 
      if(_cars == value) 
       return; 
      _cars = value; 
      RasisePropertyChanged("Cars"); 
     } 
    } 

、これは、データ層のリポジトリであってもよく、またはそれは、Entity FrameworkのDbContextのインスタンスとすることができます。したがって、ビューモデルは、DbContextから派生した型またはそのサービスのフィールドを持つことができ、ビューモデルクラスのコンストラクタに渡すことも、依存性注入を注入することもできます。また、サービスはビューモデルそのビューに表示されるデータをメンバーに移入してユーザーに表示します。

MVVMは、さまざまな方法で実装できるかなり基本的なデザインパターンです。いくつかの開発者はパターンを新しい高さに持ち、パターンのコンポーネントが通信する多くのルールに厳密に従います。最終的には、パターンの使用方法に関係なく、パターンを使用しない場合よりもはるかに優れています。これにより、コードのスケールが大幅に改善され、他の開発者がコードを理解しやすくなります。また、MVVMパターンを使用すると、WPF開発者はユニットテストを行うことができます。十分にうまくいけば、ビューモデルをテストすることができます。コードがビューの後ろにコードがなく、ビューは何もしませんが、それはわからないデータを表示するので、ビューモデルをテストするだけで十分です。

Answer 2

ドメインモデルを厳密にビューモデルとして使用すると、すぐに問題が発生することはありません。通常、ドメインモデルは生データで構成され、ビジネスオペレーションを含む場合と含まない場合があります。たとえば、BusinessLayerマネージャクラスにそのデータを配置する場合もあります。しかし、あなたはVM ViewModelは厳密にビュー用であり、ビュープロジェクト内にのみ存在する必要があります。ビュー関連のドロップダウンなどでドメインを混乱させることは、それらの「ビュー」データソースを配置するのに適切な場所ではありません。

これをコードで表現すると、ビューモデルにはドメインモデルのインスタンスを参照するプロパティを含めることができます。またはビューが公開するすべてのプロパティを追加できます。しかし、ViewModelとModel（ドメインモデル）を分離することで、ビューが必要なものを公開/非表示にし、いくつかのプロパティを変換できるようになります。例えばEntityFrameworkモデルには文字列プロパティが含まれますが、 1つの画面上での数値表現、もう1つは文字列プロパティとしての編集を許可するかもしれませんが、あなたのEFモデル（ドメインモデル）はそれらのビューの問題を心配する必要はありません。

ここでVMを作成しますか？

コントローラの仕事は、要求を解釈し、必要なビューとビューモデルを決定することです。したがって、コントローラの中には、VMのソースとしてEFドメインモデルクラス（例として編集要求用）を使用してVMが作成されます。