ASP.NET MVC Model vs ViewModel

Question

OK, I have been hearing discussion about "ViewModels" in regards to MS's ASP.NET MVC.

Now, that is intended to be a specific kind of Model, correct? Not a specific kind of View.

To my understanding, it's a kind of Model that has a specific purpose of interacting with the View? Or something like that?

Some clarification would be appreciated.

Sternmost

Answer 1

Essentially Model and View Model are both simple classes with attributes.

The main objective of these classes are to describe (to "Model") an object for their respective audiences that are respectively the controller and the view.

So you are completely right when you say

To my understanding, it's a kind of Model that has a specific purpose of interacting with the View

So, while Model classes are effectively Domain Entities that your application interact with, View Models are simple classes that your views interact with.

Hope it helps :)

Update:

Microsoft has developed a specialized version of the Presentation Pattern by Martin fowler largely based on the Model-View-Controller and called it Model-View-ViewModel (MVVM) for PF application. This pattern is targeted at modern UI development platforms where UI developers have different requirements based more on business logic than traditional developers. Have a look here for a bit of theory

Paramagnet

OK, thanks, and also thanks for the update, that's quite helpful! So, without taking into account MS's special version, with stock MVC 2, do you place ViewModels in a special, designated folder? Or are they essentially just plopped right into the Models folder like any other ones. Or, can you do either? – Sternmost

You are welcome. Usually I place models and view models in the same folder because I want to group them together respect to domain to which they refer but that's just my choice and I am sure there are better – Paramagnet

ViewModel is supposed to separate View from (domain)Model. So it makes sense to put ViewModel near View, not near Model. – Boito

I would keep my 'Model' classes outside of my MVC project rather than in a Model folder - I would however, keep the View Model classes inside the MVC project, so that, as Vitaliy says they will be near the View. – Penmanship

@Paramagnet On your first line, you say "both simple classes with attributes." I think you mean with properties? If not, to which attributes were you referring? Attributes vs. Properties – Pomeroy

@xr280xr: I meant Properties :) – Paramagnet

Answer 2

In the simplest of terms, I like to think of the following:

Model: Strictly looks and feels like your data model. For all intents and purposes it is only a class representation of your data model. It has no knowledge of your View or any elements within your View. That said, it should not contain any attribute decorators (ie; Required, Length, etc.) that you would use for your View.

View Model: Serves as a data-binder between your View and your Model and in many cases, is also a wrapper for your Model. It would be rendered useless without the View, so it typically isn't reusable across multiple Views and Controllers like a standard Model is.

As an example, your Model may have the following properties, which are direct representations of your data source:

    public string FirstName { get; set; }
    public string LastName { get; set; }

Now, since your View Model is tied to your View, it may have the following property - which concatenates the Model's FirstName field and LastName field together as one string:

    [Display(Name = "Customer Name")]                
    public string CustomerFullName { get { return String.Format("{0} {1}", myModel.FirstName, myModel.LastName) }}

Surprise

Could you provide a fuller example of the ViewModel? How does it know what myModel is and how does it get data for myModel? – Alathia

By nature, a ViewModel is a plain-old C# object (POCO) and will never truly know what your data model looks like. It is more of a hybrid of your data model and specific elements that your view needs to display. As far as how it gets data, you have to load it with the data. I like to use a separate intermediary class, where I call my service for the data and then manually load that data into my ViewModel. I then return the fully-loaded ViewModel to the controller action. – Surprise

Answer 3

I found this article a very useful resource for understanding how the "Domain Model" and "View Model" interact within an MVC application, particularly in regards to binding. Best of all includes examples instead of abstract descriptions.

"Since MVC has been released I have observed much confusion about how best to construct view models. Sometimes this confusion is not without good reason since there does not seem to be a ton of information out there on best practice recommendations. Additionally, there is not a “one size fits all” solution that acts as the silver bullet. In this post, I’ll describe a few of the main patterns that have emerged and the pros/cons of each. It is important to note that many of these patterns have emerged from people solving real-world issues."

http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

Addend

Answer 4

WikiPedia has a more complete description of Model vs. ModelView than you'll get in an SO answer: http://en.wikipedia.org/wiki/Model_View_ViewModel

I quote:

Model: as in the classic MVC pattern, the model refers to either (a) an object model that represents the real state content (an object-oriented approach), or (b) the data access layer that represents that content (a data-centric approach).

View: as in the classic MVC pattern, the view refers to all elements displayed by the GUI such as buttons, windows, graphics, and other controls.

ViewModel: the ViewModel is a “Model of the View” meaning it is an abstraction of the View that also serves in data binding between the View and the Model. It could be seen as a specialized aspect of what would be a Controller (in the MVC pattern) that acts as a data binder/converter that changes Model information into View information and passes commands from the View into the Model. The ViewModel exposes public properties, commands, and abstractions. The ViewModel has been likened to a conceptual state of the data as opposed to the real state of the data in the Model.

Plasmagel

While there is a description of Model and ViewModel, that link is just describing the MVVM architectural pattern. Not the differences between Model and View Models – Paramagnet

Answer 5

There is a notion of a ViewModel, but it is not generally associated with Asp.net MVC. MVC uses the Model View Controller patter, where the controller handles interactions, builds up data from the Model, and then passes that data to the View for display.

ViewModels (and the Model View ViewModel pattern) is more generally associated with Silverlight and WPF. Xaml is a bit different in that the views can do two-way binding to the ViewModels, so the technology is a little different. For example, if you bind a textbox to a field, as you type into that textbox, the value of the field is updated dynamically. This sort of interaction isn't really possible in web pages since web pages are stateless.

The similarity in the two patterns is that they are both trying to separate the logic from the display. The most common use/reason for this is testing: you want to be able to perform from code (via a testing framework) all the interactions that a user will invoke via the User Interface.

Smail

In the book I am reading, "Professional ASP MVC 2", ViewModel is introduced in Chapter 1 as a means of keeping presentation / model interactions both strongly typed and DRY. The microsoft authors include Scott Hansleman, Phil Haack, Scott Guthrie. – Jehanna

I've seen a lot more, lately, that the ViewModel is being used in Asp.net MVC. it would seem that the ViewModel has more business being in the view than the Domain Model. So the pattern that we've been using is to have the domain models assemble the major parts of the ViewModel. Currently, we use a modified command pattern (operations) that work with the domain models to perform their tasks. The results are assembled into the ViewModel and sent to the view. The viewmodel in this case holds all of the annotations and simple, focused logic that support the view. – Emulate