私は現在、WPFでMVVMを学習しています。CodeFirstアプローチを使用してEntityFrameworkを組み込んだアプリケーションを作成しています。私のプロジェクトの適切な構造はどうあるべきですか?
MVVMはこの構造を持っています
Views
ViewModels
Model
私の現在の計画は、POCOをModelフォルダーに入れることです。DbContextクラスから継承するクラスはどこに置くべきですか?
私は現在、WPFでMVVMを学習しています。CodeFirstアプローチを使用してEntityFrameworkを組み込んだアプリケーションを作成しています。私のプロジェクトの適切な構造はどうあるべきですか?
MVVMはこの構造を持っています
Views
ViewModels
Model
私の現在の計画は、POCOをModelフォルダーに入れることです。DbContextクラスから継承するクラスはどこに置くべきですか?
MVVMは、サービスインフラストラクチャ自体を指定しません。POCOドメインは「モデル」ディレクトリに残っている必要がありますが、DbContextはMVVM実装に認識されてはなりません。
言い換えれば、DbContextから派生したクラスがあってはなりません。
私は通常、ViewModel実装から「実際の」モデルを抽象化するViewModelProviderコンストラクトを介してそのタイプの機能を提供します。これにより、モックなどが簡単になります。すべての具体的なviewModel実装は、この抽象化によって「提供」される必要があります。
Models、Views、およびViewModelsバケットは、実際にはアプリケーションの単なるレイヤーです。それらの間の相互作用がMVVMパターンに違反しない限り、それらの実際の場所は重要ではありません。
そうは言っても、私はASP.NETMVCとT4ScaffoldingNuGetパッケージによって設定されたパターンに従う傾向があります。そのパッケージをインストールした後、次のコマンドを発行できます。
Scaffold Repository -ModelType Person
これにより、Personモデルクラスに基づいて2つの新しいクラスの足場が作成されます。
1つ目は、ご想像のとおり、単なる標準のDbContextクラスです。ビューまたはViewModlesがこのクラスと直接対話することは意図されていません。リポジトリクラスは、コンテキストの抽象化を提供します。これは、レイヤー間を通過する必要があるものです。リポジトリは、DbContaxtよりもはるかに簡単にモックでき、WCFDataServicesのようなまったく異なるテクノロジーを使用して簡単に実装できます。
うまくいけば、この答えは少なくともあなたに始めるのに良い場所を与えるでしょう。