CODEWITHSUNDEEP
asp.net-mvc
Sam
Sam

Reputation: 15771

ViewModel Questions

For the sake of simplicity, lets say I have a CustomerViewModel and I want to display their basic information (Name, Email, Phone, etc.) as well as a list of recent orders.

Should I have a collection property, say Orders of type OrderListViewModel, or should I use the POCO objects returned from the Repository?

I guess what I am really asking is should I have a View Model for every entity and then have collections of those attached to "Parent" View Models?

Upvotes: 3

Views: 216

Answers (4)

Paul
Paul

Reputation: 12440

Yes, You should have ViewModels but you don't have to. If you are following DDD then you would never have a Entity reach the View. I have started small apps where I just used my domain objects as the Model for my views and later as the app grew regretted the design decision.

Here is a good post on the View Model pattern and how to use Automapper to help with the additional left to right: http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx

http://www.bengtbe.com/blog/post/2009/04/14/Using-AutoMapper-to-map-view-models-in-ASPNET-MVC.aspx

Your ViewModel should look something like this:

public class CustomerModel {
    public string Name {get; set;}
    public string Email {get; set;}
    public string Phone {get; set;}
    public OrderModel[] Orders {get; set;}

  public class OrderModel {
    public int OrderNumber {get; set;}
    public double OrderTotal {get; set;}
  }
}

Configure Automapper and will will keep all your concerns separated (SoC)

Upvotes: 3

leora
leora

Reputation: 196499

Don't just create a view model for no reason. The view model should provide specific value of decoupling the model from the view as well as add additional items (dropdown lists, etc) that the specific view needs that you don't want to put in your model. A view model should map 1 to 1 to a specific view.

If you don't have that need right now for the above then don't create it.

i don't think there is anything wrong with starting with just the POCOs and creating viewmodels when you need them. I dont see a big issue with refactoring and creating a view model at the point that you need the decoupling in between your view and your model. For trivial cases i would avoid over engineering up front but know that your goal is to ultimately have view models as a solution to avoid coupling or add extra things the view needs.

Upvotes: 2

alexn
alexn

Reputation: 58962

Basically, you should have a unique View Model for every unique view. The View Model should contain all data the view is going to present.

So, if you're presenting customer information along with orders, the View Model could have a customer instance and a order list:

class ViewModel
{
    Customer Customer { get; set; }
    IEnumerable<Order> Orders { get; set; }
}

I would recommend using a View Model even when a simple business object would do just fine. This makes it so much more easy to maintain and as we all know, requirements change.

AutoMapper is a wonderful tool that makes dealing with View Models a breeze.

Upvotes: 3

Bala R
Bala R

Reputation: 108957

Ideally you should have View Model for for every entity that the view deals with. Sometimes when the entity is too trivial, you could skip having a view Model I guess.

Upvotes: 0

Related Questions