Dfyjkt

View model is a class that represents the data model used in a specific view. We could use this class as a model for a login page:

public class LoginPageVM

 [Required(ErrorMessage = "Are you really trying to login without entering username?")]
 [DisplayName("Username/e-mail")]
 public string UserName get; set; 
 [Required(ErrorMessage = "Please enter password:)")]
 [DisplayName("Password")]
 public string Password get; set; 
 [DisplayName("Stay logged in when browser is closed")]
 public bool RememberMe get; set; 

Using this view model you can define the view (Razor view engine):

@model CamelTrap.Models.ViewModels.LoginPageVM

@using (Html.BeginForm()) 
 @Html.EditorFor(m => m);
 <input type="submit" value="Save" class="submit" />

And actions:

[HttpGet]
public ActionResult LoginPage()

 return View();


[HttpPost]
public ActionResult LoginPage(LoginPageVM model)

 ...code to login user to application...
 return View(model);

Which produces this result (screen is taken after submitting form, with validation messages):

As you can see, a view model has many roles:

• View models documents a view by consisting only fields, that are represented in view.


• View models may contain specific validation rules using data annotations or IDataErrorInfo.


• View model defines how a view should look (for LabelFor,EditorFor,DisplayFor helpers).


• View models can combine values from different database entities.


• You can specify easily display templates for view models and reuse them in many places using DisplayFor or EditorFor helpers.

Another example of a view model and its retrieval: We want to display basic user data, his privileges and users name. We create a special view model, which contains only the required fields. We retrieve data from different entities from database, but the view is only aware of the view model class:

public class UserVM 
 public int ID get; set; 
 public string FirstName get; set; 
 public string LastName get; set; 
 public bool IsAdministrator get; set; 
 public string MothersName get; set; 

Retrieval:

var user = db.userRepository.GetUser(id);

var model = new UserVM() 
 ID = user.ID,
 FirstName = user.FirstName,
 LastName = user.LastName,
 IsAdministrator = user.Proviledges.IsAdministrator,
 MothersName = user.Mother.FirstName + " " + user.Mother.LastName
 

Edit: I updated this answer on my Blog:

http://www.samwheat.com/Post/The-function-of-ViewModels-in-MVC-web-development

My answer is a bit lengthy but I think it is important to compare view models to other types of commonly used models to understand why they are different and why they are necessary.

To summarize, and to directly answer the question that is asked:

Generally speaking, a view model is an object that contains all the properties and methods necessary to render a view. View model properties are often related to data objects such as customers and orders and in addition they also contain properties related to the page or application itself such as user name, application name etc. View models provide a convenient object to pass to a rendering engine to create a html page. One of many reasons to use a view model is that view models provide a way to unit test certain presentation tasks such as handling user input, validating data, retrieving data for display, etc.

Here is a comparison of Entity models (a.ka. DTO's a.ka. models), Presentation Models, and View Models.

Data Transfer Objects a.k.a “Model”

A Data Transfer Object (DTO) is a class with properties that match a table schema in a database. DTO’s are named for their common usage for shuttling data to and from a data store.

Characteristics of DTO’s:

• Are business objects – their definition is dependent on application data.

• Usually contain properties only – no code.

• Primarily used for transporting data to and from a database.

• Properties exactly or closely match fields on a specific table in a data store.

Database tables are usually normalized therefore DTO’s are usually normalized also. This makes them of limited use for presenting data. However, for certain simple data structures they often do quite well.

Here are two examples of what DTO’s might look like:

public class Customer

 public int ID get; set; 
 public string CustomerName get; set; 



public class Order

 public int ID get; set; 
 public int CustomerID get; set; 
 public DateTime OrderDate get; set; 
 public Decimal OrderAmount get; set; 

Presentation Models

A presentation model is a utility class that is used to render data on a screen or report. Presentation models are typically used to model complex data structures that are composed from data from multiple DTO’s. Presentation models often represent a denormalized view of data.

Characteristics of Presentation Models:

• Are business objects – their definition is dependent on application data.

• Contain mostly properties. Code is typically limited to formatting data or converting to or from a DTO. Presentation Models should not contain business logic.

• Often present a denormalized view of data. That is, they often combine properties from multiple DTO’s.

• Often contain properties of a different base type than a DTO. For example dollar amounts may be represented as strings so they can contain commas and a currency symbol.

• Often defined by how they are used as well as their object characteristics. In other words, a simple DTO that is used as the backing model for rendering a grid is in fact also a presentation model in the context of that grid.

Presentation models are used “as needed” and “where needed” (whereas DTO’s are usually tied to the database schema). A presentation model may be used to model data for an entire page, a grid on a page, or a dropdown on a grid on a page. Presentation models often contain properties that are other presentation models. Presentation models are often constructed for a single-use purpose such as to render a specific grid on a single page.

An example presentation model:

public class PresentationOrder

 public int OrderID get; set; 
 public DateTime OrderDate get; set; 
 public string PrettyDate get return OrderDate.ToShortDateString(); 
 public string CustomerName get; set; 
 public Decimal OrderAmount get; set; 
 public string PrettyAmount get return string.Format("0:C", OrderAmount); 

View Models

A view model is similar to a presentation model in that is a backing class for rendering a view. However it is very different from a Presentation Model or a DTO in how it is constructed. View models often contain the same properties as presentation models and DTO’s and for this reason they are often confused one for the other.

Characteristics of View Models:

• Are the single source of data used to render a page or screen. Usually this means that a view model will expose every property that any control on the page will need to render itself correctly. Making the view model the single source of data for the view greatly improves its capability and value for unit testing.

• Are composite objects that contain properties that consist of application data as well as properties that are used by application code. This characteristic is crucial when designing the view model for reusability and is discussed in the examples below.

• Contain application code. View Models usually contain methods that are called during rendering and when the user is interacting with the page. This code typically relates to event handling, animation, visibility of controls, styling, etc.

• Contain code that calls business services for the purpose of retrieving data or sending it to a database server. This code is often mistakenly placed in a controller. Calling business services from a controller usually limits the usefulness of the view model for unit testing. To be clear, view models themselves should not contain business logic but should make calls to services which do contain business logic.

• Often contain properties which are other view models for other pages or screens.

• Are written “per page” or “per screen”. A unique View Model is typically written for every page or screen in an application.

• Usually derive from a base class since most pages and screens share common properties.

View Model Composition

As stated earlier, view models are composite objects in that they combine application properties and business data properties on a single object. Examples of commonly used application properties that are used on view models are:

• Properties that are used to display application state such as error messages, user name, status, etc.

• Properties used to format, display, stylize, or animate controls.

• Properties used for data binding such as list objects and properties that hold intermediate data that is input by the user.

The following examples show why the composite nature of view models is important and how we can best construct a View Model that efficient and reusable.

Assume we are writing a web application. One of the requirements of the application design is that the page title, user name, and application name must be displayed on every page. If we want to create a page to display a presentation order object, we may modify the presentation model as follows:

public class PresentationOrder

 public string PageTitle get; set; 
 public string UserName get; set; 
 public string ApplicationName get; set; 
 public int OrderID get; set; 
 public DateTime OrderDate get; set; 
 public string PrettyDate get return OrderDate.ToShortDateString(); 
 public string CustomerName get; set; 
 public Decimal OrderAmount get; set; 
 public string PrettyAmount get return string.Format("0:C", OrderAmount); 

This design might work… but what if we want to create a page that will display a list of orders? The PageTitle, UserName, and ApplicationName properties will be repeated and become unwieldy to work with. Also, what if we want to define some page-level logic in the constructor of the class? We can no longer do that if we create an instance for every order that will be displayed.

Composition over inheritance

Here is a way we might re-factor the order presentation model such that it become a true view model and will be useful for displaying a single PresentationOrder object or a collection of PresentationOrder objects:

public class PresentationOrderVM

 // Application properties
 public string PageTitle get; set; 
 public string UserName get; set; 
 public string ApplicationName get; set; 

 // Business properties
 public PresentationOrder Order get; set; 



public class PresentationOrderVM

 // Application properties
 public string PageTitle get; set; 
 public string UserName get; set; 
 public string ApplicationName get; set; 

 // Business properties
 public List<PresentationOrder> Orders get; set; 

Looking at the above two classes we can see that one way to think about a view model is that it is a presentation model that contains another presentation model as a property. The top level presentation model (i.e. view model) contains properties that are relevant to the page or application while presentation model (property) contains properties that are relevant to application data.

We can take our design a step further and create a base view model class that can be used not only for PresentationOrders, but for any other class as well:

public class BaseViewModel

 // Application properties
 public string PageTitle get; set; 
 public string UserName get; set; 
 public string ApplicationName get; set; 

Now we can simplify our PresentationOrderVM like this:

public class PresentationOrderVM : BaseViewModel

 // Business properties
 public PresentationOrder Order get; set; 


public class PresentationOrderVM : BaseViewModel

 // Business properties
 public List<PresentationOrder> Orders get; set; 

We can make our BaseViewModel even more re-usable by making it generic:

public class BaseViewModel<T>

 // Application properties
 public string PageTitle get; set; 
 public string UserName get; set; 
 public string ApplicationName get; set; 

 // Business property
 public T BusinessObject get; set; 

Now our implementations are effortless:

public class PresentationOrderVM : BaseViewModel<PresentationOrder>

 // done!


public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>

 // done!

If you have properties specific to the view, and not related to the DB/Service/Data store, it is a good practice to use ViewModels. Say, you want to leave a checkbox selected based on a DB field (or two) but the DB field itself isn't a boolean. While it is possible to create these properties in the Model itself and keep it hidden from the binding to data, you may not want to clutter the Model depending on the amount of such fields and transactions.

If there are too few view-specific data and/or transformations, you can use the Model itself

I didn't read all the posts but every answer seems to be missing one concept that really helped me "get it"...

If a Model is akin to a database Table, then a ViewModel is akin to a database View - A view typically either returns small amounts of data from one table, or, complex sets of data from multiple tables (joins).

I find myself using ViewModels to pass info into a view/form, and then transfering that data into a valid Model when the form posts back to the controller - also very handy for storing Lists(IEnumerable).

MVC doesn't have a viewmodel: it has a model, view and controller. A viewmodel is part of MVVM (Model-View-Viewmodel). MVVM is derived from the Presentation Model and is popularized in WPF. There should also be a model in MVVM, but most people miss the point of that pattern completely and they will only have a view and a viewmodel. The model in MVC is similar to the model in MVVM.

In MVC the process is split into 3 different responsibilities:

• View is responsible for presenting the data to the user


• A controller is responsible for the page flow


• A model is responsible for the business logic

MVC is not very suitable for web applications. It is a pattern introduced by Smalltalk for creating desktop applications. A web environment behaves completely different. It doesn't make much sense to copy a 40-year old concept from the desktop development and paste it into a web enviroment. However a lot of people think this is ok, because their application compiles and returns the correct values. That is, in my opinion, not enough to declare a certain design choice as ok.

An example of a model in a web application could be:

public class LoginModel

 private readonly AuthenticationService authentication;

 public LoginModel(AuthenticationService authentication)
 
 this.authentication = authentication;
 

 public bool Login()
 
 return authentication.Login(Username, Password);
 

 public string Username get; set; 
 public string Password get; set; 

The controller can use it like this:

public class LoginController

 [HttpPost]
 public ActionResult Login(LoginModel model)
 
 bool success = model.Login();

 if (success)
 
 return new RedirectResult("/dashboard");
 
 else
 
 TempData["message"] = "Invalid username and/or password";
 return new RedirectResult("/login");
 
 

Your controller methods and your models will be small, easily testable and to the point.

A lot of big examples, let me explain in clear and crispy way.

ViewModel = Model that is created to serve the view.

ASP.NET MVC view can't have more than one model so if we need to display properties from more than one models into the view, it is not possible. ViewModel serves this purpose.

View Model is a model class that can hold only those properties that is required for a view. It can also contains properties from more than one entities (tables) of the database. As the name suggests, this model is created specific to the View requirements.

Few examples of View Models are below

• To list data from more than entities in a view page – we can create a
  View model and have properties of all the entities for which we want
  to list data. Join those database entities and set View model
  properties and return to the View to show data of different
  entities in one tabular form


• View model may define only specific fields of a single entity that is
  required for the View.

ViewModel can also be used to insert, update records into more than one entities however the main use of ViewModel is to display columns from multiple entities (model) into a single view.

The way of creating ViewModel is same as creating Model, the way of creating view for the Viewmodel is same as creating view for Model.

Here is a small example of List data using ViewModel.

Hope this will be useful.

View model a is simple class which can contain more than one class property. We use it to inherit all the required properties, e.g. I have two classes Student and Subject

Public class Student

public int Id get; set;
public string Name get; set;
 
Public class Subject

public int SubjectID get; set;
public string SubjectName get; set;

Now we want to display records student's Name and Subject's Name in View (In MVC), but it's not possible to add more than one classes like:

 @model ProjectName.Model.Student 
 @model ProjectName.Model.Subject

the code above will throw an error...

Now we create one class and can give it any name, but this format "XyzViewModel" will make it easier to understand. It is inheritance concept.
Now we create a third class with the following name:

public class StudentViewModel:Subject

public int ID get; set;
public string Name get; set;

Now we use this ViewModel in View

@model ProjectName.Model.StudentViewModel

Now we are able to access all the properties of StudentViewModel and inherited class in View.

ViewModel is workarround that patches the conceptual clumsiness of the MVC framework. It represents the 4th layer in the 3-layer Model-View-Controller architecture. when Model (domain model) is not appropriate, too big (bigger than 2-3 fields) for the View, we create smaller ViewModel to pass it to the View.

A view model is a conceptual model of data. Its use is to for example either get a subset or combine data from different tables.

You might only want specific properties, so this allows you to only load those and not additional unneccesary properties

• ViewModel contain fields that are represented in the view (for
  LabelFor,EditorFor,DisplayFor helpers)


• ViewModel can have specific validation rules using data annotations
  or IDataErrorInfo.


• ViewModel can have multiple entities or objects from different data
  models or data source.

Designing ViewModel

public class UserLoginViewModel 
 
[Required(ErrorMessage = "Please enter your username")] 
[Display(Name = "User Name")]
[MaxLength(50)]
public string UserName get; set; 
 [Required(ErrorMessage = "Please enter your password")]
 [Display(Name = "Password")]
 [MaxLength(50)]
 public string Password get; set; 
 

Presenting the viewmodel in the view

@model MyModels.UserLoginViewModel 
@
 ViewBag.Title = "User Login";
 Layout = "~/Views/Shared/_Layout.cshtml";

@using (Html.BeginForm())

<div class="editor-label">
 @Html.LabelFor(m => m.UserName)
</div>
<div class="editor-field">
 @Html.TextBoxFor(m => m.UserName)
 @Html.ValidationMessageFor(m => m.UserName)
</div>
<div class="editor-label">
 @Html.LabelFor(m => m.Password)
</div>
<div class="editor-field">
 @Html.PasswordFor(m => m.Password)
 @Html.ValidationMessageFor(m => m.Password)
</div>
<p>
 <input type="submit" value="Log In" />
</p>
</div>

Working with Action

public ActionResult Login()
 
return View();

[HttpPost]
public ActionResult Login(UserLoginViewModel user)

// To acces data using LINQ
DataClassesDataContext mobjentity = new DataClassesDataContext();
 if (ModelState.IsValid) 
 
try
 
 var q = mobjentity.tblUsers.Where(m => m.UserName == user.UserName && m.Password == user.Password).ToList(); 
 if (q.Count > 0) 
 
 return RedirectToAction("MyAccount");
 
 else
 
 ModelState.AddModelError("", "The user name or password provided is incorrect.");
 
 
 catch (Exception ex)
 
 
 
 return View(user);
 

1. In ViewModel put only those fields/data that you want to display on
   the view/page.


2. Since view reperesents the properties of the ViewModel, hence it is
   easy for rendering and maintenance.


3. Use a mapper when ViewModel become more complex.