views:

164

answers:

3

Hi guys,

Short question - how do you define your view models?

Here are some of the options:

  1. Pass the actual model into the view.
  2. Create a view model with a reference to the model (like Model.Product)
  3. Create a view model with the properties needed from the model, and set those from the model.
  4. Probably a lot more.

All with their own advantages and disadvantages.

What is your experience - good and bad? And do you use the same model for GET/POST?

Thanks for your input!

A: 

In my projects, it's a mix really.

If I want to display a form with details of Customer X, I just pass a DAL Customer object to my view. It's really no use to create a seperate ViewModel for it, map all its properties, and then display them. It's a waste of time imho.

Sometimes though, models are a bit more complex. They're the result of multiple queries, have some added data to them, so in these cases, I create a custom ViewModel, and add the necessary data from my model to it. In your case, it would be option 2, or sometimes 3. I prefer that over passing my model and having to add an additional 10 items in my ViewData.

Razzie
Do NOT mix them! It's a pain! Been there. Mixing will look cute only @ the beginning, it will trick you into nightmare! :D
Arnis L.
+1  A: 

Basically - it's all about separating responsibilities.

More you separate them - more verbose, complex but easier to understand it gets.


Model:

public class foo{
    string Name{get;set}
    Bar Bar {get;set;}
    string SomethingThatIsUneccessaryInViews {get;set;}
}

public class bar{
    string Name {get;set;}
}

public class fizz{
    string Name{get;set;}
}

Presenter (i admit - still haven't got idea of MVP completely):

public someSpecificViewPresenter{
    fizz fizz{get;set;}
    foo foo{get;set;}
    necessaryThingsForWhatever[] necessaryThingsForWhatever{get;set;}
    public void someLogicIfNeeded(){...}        
}

magic object2object mapping & flattening, viewmodel modelmetadata configuration goes here...

ViewModel (NB=>POCOS with container props only. No logic should go here.):

public class fooViewModel{
    string Name {get;set;}
    string BarName {get;set;}
}

public class fizzViewModel{
    string Name {get;set;}
}

public class someSpecificView{
    fooViewModel foo {get;set;}
    fizzViewModel fizz {get;set;}
    whateverViewModel whatever {get;set;}
}

and here goes "das happy ending"...

<use viewdata="someSpecificView m" />

<p>
Our foo:<br/>
${Html.DisplayFor(x=>x.foo)}
</p>

<p>
Our fizz:<br/>
${Html.DisplayFor(x=>x.fizz)}
</p>

${Html.UberPaging(m.whatever.Paging)}

And yes, i use same model for GET/POST. See this for more why/ifs.


But lately - I'm looking for other solutions. CQRS buzz catch my eye.

Arnis L.
I'm with you on this approach. Mappers like AutoMapper can handle the flattening from complex models to a flat view object.As for CQRS, I'm looking into that too, and I think that makes for more "natural" view objects.
lasseeskildsen
A: 

I grabbed the T4 templates from SubSonic 3. These were modified and I added some new ones. I can run one of them and it generates 3 separate view models for each table. Then I can modify as needed.

Why three?

  1. FormModel - contains on the data necessary for displaying in a form for editing or creation. Foreign keys get converted to SelectLists. DateTime fields get split into date and time components.

  2. PostModel - this is the object returned from the Form Post. DropDownLists are posted as Int or equivalent type. Only the necessary members are in the model.

  3. DisplayModel - used for non-editing display of the data.

I always generated these in a subfolder named Generated. As I hand tweek them I move them to the Models folder. It doesn't completely automate the process, but it generates a lot of code I would otherwise generate by hand.

37Stars