24

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.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
user9969
  • 15,632
  • 39
  • 107
  • 175

3 Answers3

38

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.

ViewModels 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 ViewModels in my Views, 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);
}
Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
RPM1984
  • 72,246
  • 58
  • 225
  • 350
  • 2
    Hi,thanks for your reply,are you saying:We dont have models inside our webApp.We have ViewModels that the controllers refers to and then we inject the Domain "Model" into the viewModel,so that we can add annotations and validation to our ViewModels.Do you have a quick example somewhere or link our this is structured?I would be very grateful.thanks – user9969 May 31 '11 at 09:35
  • 1
    That's **exactly** what im saying - well done summing it up in a single sentence. Now of course, your web application will still need to **reference** the domain model assembly, as it needs to map back and forth between them. But the kicker is your views have no idea about your domain models, they bind to the ViewModels. Decent example here: http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx. Just google around for "asp.net mvc view model pattern" – RPM1984 May 31 '11 at 09:39
  • i also added a very simple example with AutoMapper. – RPM1984 May 31 '11 at 09:42
  • Thanks.I will look into those links.The problem is that all those example out there a very simplistic ,especially the Microsoft ones and if you have doubts you are stuck and not sure what is a good and sort of "standard" architecture.Thanks a lot – user9969 May 31 '11 at 09:52
3

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.

BonyT
  • 10,750
  • 5
  • 31
  • 52
  • Hi thanks for your reply.My views will have no idea of database. They will call a "ViewModels" and those a Service Layer and from there a DAL.All via interfaces.From what you are saying the MVVM is actually the pattern to use in MVC.Is this what you are saying? – user9969 May 31 '11 at 09:38
  • Sorry - my final sentence confused - I did not mean the Views referenced the database - I will update. I meant how closely the structure required in the ViewModel matches that used in the database. But in answer to your question - yes - in your case a ViewModel would be my choice. – BonyT May 31 '11 at 09:46
0

Extremely simple, ViewModel can be the combination of multiple Model classes, to display or transforming the data to and from within the Network, may be via API calls.

However, Model class is nothing but just be specific to any particular entity, Object or strict to a particular Table.

Ex- For "EmployeeViewModel" can be the combinations of Multiple Model Classes i.e. EmpBasicDetails + EmpAddressDetails +EmpExperienceSummary. Whereas, "EmpBasicDetails" - is specific Model class which contains the Employee Details specifically.

~Cheers,