CODEWITHSUNDEEP
asp.net-mvc
Cris
Cris

Reputation: 12194

How to use ViewModel in ASPNET MVC3

I'm trying to learn ASPNET MVC. I've built a DbModel starting from DB structure so, under Models, I have the .edmx file that can be used to access data.

I've read that it could be good to have ViewModels classes to act between the View and the Model (useful also for single fields formatting) but I don't' understand if this is right and in which way it's better to build them. If they reproduce classes in my model I believe it is a little bit redundant, isn't it? If this is the right way, is there a way to generate automatically ViewModel classes?

Upvotes: 2

Views: 713

Answers (3)

Daniel Young
Daniel Young

Reputation: 436

If you are just starting out I would avoid trying to incorporate every best practice you can find into your early applications. It becomes very easy to try and do everything everyone says is the best practice and you lose track of just learning the fundamentals.

View Models are obviously a great way of seperating the presentation layer and the domain layer, but they serve other purposes. If you are just starting out and your applications are not terribly complicated, I would recommend keeping it simple and use your domain classes as your view model where your views are simple. This will allow you to focus more on the application.

Also, by doing this you will come across views where the simple domain model will not cut it and you will find yourself needing a ViewModel. Which will allow you to incorporate the more specific information you need for your view page (such as multiple domain objects).

By practicing without using View Models for everything, you can gain an appreciation for their benefits and decide what works best for you and your code.

Upvotes: 2

codeprogression
codeprogression

Reputation: 3441

A ViewModel in MVC is a model of your view. It is a property bag containing, usually of primitive types. It may seem redundant, but you are protecting yourself from future problems by decoupling your code.

As an example, given a Person object in your domain model:

public class Person
{
    public string FirstName {get; set;}     // John
    public string LastName {get; set;}      // Doe
    public DateTime Birthdate {get; set;}   // 01/01/1965
}

In your view, you may want to represent this in a view as a full name, age and birthday. Your ViewModel would be similar to:

public class PersonViewModel
{
    public string FullName {get; set;}     // John Doe
    public int Age {get; set;}             // 46
    public int Birthday {get; set;}        // January 1
}

Somewhere in your pipeline, you need to convert from domain model to the viewmodel. I have used either projection queries from the persistence layer or object-to-object mapping frameworks, such as AutoMapper.

By structuring your data this way, you can keep logic and formatting rules out of your view markup. By using a framework, such as AutoMapper, you can also standardize string formatting of dates and times, and do convention-based mappings.

Also, I generally advise having one ViewModel per View. If you need to share View/ViewModel structures or apply conditional view information, those should be separated into partial views.

Upvotes: 3

Gregory A Beamer
Gregory A Beamer

Reputation: 17010

A "view model" (model for a view rather than domain model) helps you separate the domain model from what is bound to the page. Is it always necessary? No, but it is useful if you have some common data shapes used on multiple views where the view will also have some additional data. Another good use is removing certain data from certain types of views (your customer should not know your margin, but your management should?). IT is not mandatory.

Upvotes: 1

Related Questions