ASP.NET MVCを学習していて、いくつかのサンプルアプリをダウンロードしています。 MusicStoreなど...
私はMVVMパターンがあったwpfのバックグラウンドから来ています。モデルとViewModelの概念を使用していることに気づきました。
MVVMでは、モデルをviewModelに注入するViewModelにビューをバインドしていることは明らかです。 MVCにはコントローラーがありますが、ViewModelに注入されたモデルが表示されないため、すべてがどのように結び付いているのかわかりません。
私は次の構造を持っています
私が見たいくつかの例から、あなたのモデルがViewModelとして機能することがわかりました。
コントローラーを持っていこう
public class ProductController
{
public ProductController(IProductRepository productRepository)
{
//omitted as not relevant
}
}
public class ProductVM
{
public ProductVM()
{
// Shouldn't we inject the model here RG Product
}
}
参照できるN層の例はありますか? ViewModelの概念はMVCで有効なものですか?基準は何ですか?
提案をありがとう。
ViewModelsを使用して、ビューをsimplifyします。
たとえば、製品、注文、顧客などを含む深いオブジェクトグラフがあり、これらの各オブジェクトからの情報が特定のビューで必要な場合があります。
ViewModelは、ビューに必要な情報を単一のオブジェクトに集約する方法を提供します。
ViewModelは、モデルが「ドメイン固有」に留まる必要があるため、モデルに属さないデータの注釈や検証なども可能にします。
しかし実際には、ViewModelはドメインオブジェクトの単純なラッパーにすぎません。
AutoMapperなどのツールを使用して、ViewModelとドメインモデル間を簡単にマッピングできます。
個人的に私はalways自分のビューのViewModelにバインドします。単一のオブジェクトであっても、ドメインモデルにはバインドしません。どうして?まあ、UIHints、検証、データアノテーションを使ってViewModelを装飾するのが好きです。ドメインモデルがドメイン固有のルールとビジネスロジックで強化されるのと同じ方法で、ViewModelがUI固有のロジックで強化される必要があります。
ドメインモデルの1-1表現を持つオブジェクトがあるだけの場合、ViewModelsのポイントがありません。
特定のビューに必要なものだけをViewModelsにのみ追加します。
コントローラアクションの例
public ActionResult CustomerInfo(int customerId)
{
// Fetch the customer from the Repository.
var customer = _repository.FindById(customerId);
// Map domain to ViewModel.
var model = Mapper.Map<Customer,CustomerViewModel>(customer);
// Return strongly-typed view.
return View(model);
}
MVCとMVVMの違いは、MVCにはデータエンティティ用のクラスのセットが1つあることです。 MVVMには2つあります。1つはビューにバインドするためのセットで、もう1つはデータの永続性を管理するためのセットです(たとえば、別のWCFサービスにある場合があります)。
MVVMの利点は、ビューにバインドされたモデルがUIに関連し、永続モデルから完全に独立していることです。
どちらを使用しますか?それは、ビューで必要なデータ構造がデータベースの構造にどの程度密接にマップされているかによって異なります。それが似ている場合-DALから直接ビューにDataEntitiesをバインドすることが可能です-これは古典的なMVCパターンです。ただし、DALが関係しないビュー固有の動作(検証など)を使用してこれらのクラスを拡張できるため、個別のViewModelを使用すると多くのことが得られます。
最も単純なアプリケーションを除いて、別のViewModelを使用することをお勧めします。