Confused with Model vs ViewModel

Question

I am Learning ASP.NET MVC and downloaded a couple of sample apps. MusicStore etc...

I am coming from a wpf background where we had the MVVM Pattern. I have noticed that they used the concept of model and ViewModel.

In MVVM is pretty clear that you bind the view to the ViewModel injecting the model into the viewModel. In MVC you have a controller but I am not sure and confused how the all ties together,as I cannot see the model injected into the ViewModel

I have the following structure

1. MyCompany.Entities.dll (All the models go here) EG Product
2. MyCompany.Dal.dll (All the repositories go here)
3. MyCompany.Services.dll (called by MyCompany.WebUI.Controller calls MyCompany.Dal)
4. MyCompany.WebUI.MyApp
5. MyCompany.Tests

From some of the examples I have seen your Model acts as a ViewModel.Am I correct?

Let's take a controller i have something like

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     } } 

Is there some N-tier examples out there I can refer to? Is the concept of ViewModel a valid one in MVC? What is the standard?

Thanks for any suggestions.

Answer 1

Use ViewModels to simplify the View.

For instance, you might have a deep object graph with Products, Order, Customers, etc - and some information from each of these objects are required on a particular View.

A ViewModel provides a way to aggregate the information required for a View into a single object.

ViewModel's also allow for things like data annotations and validation - which does not belong on your model, as your model should stay "domain-specific".

But in reality, ViewModels are nothing more than a simple wrapper for your domain objects.

Use a tool like AutoMapper to map back and forth between your ViewModels and domain models with ease.

Personally i always bind to ViewModel's in my View's, never to the domain models, even if it's a single object. Why? Well i like to decorate my ViewModels with UIHints, validation, data annotations. Just the same way your domain models are enriched with domain-specific rules and business logic, so should your ViewModels be enriched with UI-specific logic.

If you simply have a object with a 1-1 representation of your domain model, you are missing the point of ViewModels.

Add to the ViewModels only, and nothing more, what is required for a particular View.

Example controller action

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); } 

Answer 2

The difference between MVC and MVVM is that MVC has one set of classes for the data entities. In MVVM you have 2 - one set for binding to your views, and one set for managing the data persistence (which could be in a separate WCF service for example).

The benefits of MVVM are that the model bound to the views is relevant to the UI and completely independant from the persistence Model.

Which to use? Well it depends on how closely the data structure required by your Views maps to the structure of the database. When it is similar - it is possible to bind the DataEntities from your DAL directly to your view - this is the classic MVC pattern. However, you gain much with a separate ViewModel as you can extend these classes with View specific behaviour (e.g. Validation) that your DAL should not be concerned with.

For all but the most simple applications, I would recommend use of a separate ViewModel.