How to avoid needing a VIewModel for every Model

I'm using ASP.NET 4 and MVC3.

Often, I find that I need a ViewModel to display information for my Model. For example, take the following model

class Profile
{
   public int UserID { get; set; }
   public string Name { get; set; }
   public DateTime DOB { get; set; }
}

There is a requirement to hide the UserID, but to show the UserName, so often time for models that are similar to the one above, I have to come up with a ViewModel with just the UserID changed to UserName:

class ProfileViewModel
{
   public string UserName { get; set; }
   public string Name { get; set; }
   public DateTime DOB { get; set; }
}

Are there any wa开发者_如何学运维ys?

Until recently I always passed my models to my action methods as I also thought that creating viewModels with the same property names was duplication (its not). This caused me a lot of pain. I have now been re-educated and almost always use viewModels exclusively in my action methods (of course there will always be situations were it is fine to pass the model directly to the action method).

Have a read of this post which is the one that converted me to using viewModels. This will tell you the following:

1. The difference between models and viewModels
2. When each should be used.
3. How to avoid some security issues with the default model binder.

On top of the information in the linked post you should also consider things such as validation. I had a model that implemented the IValidateableObject interface to ensure the entity was in a valid state before being saved to the database.

In my ASP.NET application I wanted to create a multi-step form that allowed the user to enter the information over a number of pages. The problem I had here was that ASP.NET also uses the IValidatableObject interface during the model binding process.

If you are only allowing the user to enter a subset of the information required for the entity, the model binder will only be able to fill in the information that was given. Depending on how complex your validation is, this can result in the ModelState being marked as invalid as the entire entity is not valid.

The way I got around this was to have a viewModel representing each step each with its own validation. This way you are only validating the properties at each step. Once you get to the final step and everything is valid, I create an appropriate entity using the information given by the user. This entity will only have database-level validation checks performed upon it (field lengths etc.)

My suggestion is not to avoid viewModels but to understand why they are used and embrace them.

No, there isn't, once a member is public, it's public. Now, if the UserID property was internal, then you wouldn't have that problem.

However, one of the aims of MVVM here is to encapsulate logic regarding the interaction of the model and the view. Even if you have the view model and model in separate assemblies and make the UserID property internal, you should still have a view model; if changes come down the line where more functionality is required than simply binding to the model, you are prepared.

Direct access to the model is always a no no.

Additionally, if you really wanted, you could always use T4 templates to auto-generate the code for you (you could use Code DOM on the original CS file) to output your view models for you.

I usually have multiple ViewModels per model - the tradeoff you have to make comes down to this:

1. Are you comfortable coupling business logic (data annotations, display information, etc...) with your (persistence) models?
2. Are you comfortable doing all of the hide / display business logic purely within the View and not use the Controller + scaffolding to make those decisions for you?

The downside of creating all of those ViewModels of course is sub-class explosion, but the right way to think about it is in terms of the questions I listed IMHO.