ViewModel classes VS defining an Exclude Bind list on the domain class

Question

I have a model class named Server, it contains many navigation properties and properties, which I want to prevent users from binding it. So I find two approaches of doing so to avoid over-posting attacks.

The first approach is to go to each model class and define an Exclude Bind list , with all the properties and navigating properties that should not be bind by users , as follow:-

[MetadataType(typeof(TMSServer_Validation))]

 [Bind(Exclude = "Technology,IT360SiteID, VirtualMachines, TMSServer1,DataCenter,OperatingSystem,Rack,ServerModel,TechnologyBackUpStatu,TechnologyRole,TechnologyStatu ")]
    public partial class Server     {

    }
}

The second approach is to create a view model class , with only the properties that can be modified by users as follow:-

public class ServerViewModel
{
     public int ServerSize { get; set; }
   [Required]    
   public String OperatingSystem { get; set; }
   public String Commnet { get; set; }


}

I find that the first approach is faster to implement , as I only need to define the Exclude list, while the second approach will require me to create view-model class for each of the domain classes. So which approach is recommended to use and why ? Thanks

Answer 1

Over-posting occurs due to the default model binder not knowing which fields you actually included in the form. It will try to map all values in the request to object. Attackers can use your form to add additional fields to query strings/form post data and add properties as part of the request. The default model binder won't know the difference. Your Server class will deactivate once the mapping is complete and the update is processed. To prevent over-posting, set the annotation to include fields in the binding, or create a ViewModel like you mentioned in your code.

So which approach is recommended to use and why ?

Both annotation and ViewModel allow binding only on specified fields, but when you use ViewModel you will not bind against business objects or entities, and you will only have properties available for the input you expected. Once the model is validated, you can then move values from the input model to the object you used in the next layer.

k. Soctt Allen has a good article about which approach is better, you can take a look at by the following link:

http://odetocode.com/blogs/scott/archive/2012/03/11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx

Answer 2

It's difficult to tell without seeing the rest of your code, but in general I'd say using the ViewModel is probably a better approach for the following reasons:

• You separate your view from your business logic
• It is safer. If in the future someone adds a property on Server and forgets the Bind-exclude, you're exposed to over-binding without knowing it. If you use the ViewModel-approach you have to explicity add new properties

Answer 3

Maybe this question is a little bit ambiguous because the answers are going to be based on opinions or something. But I'll try to answer it the best I can and indeed is kind of my opinion. So this is the way I see it:

• First approach (Bind attribute): Is faster to implement because you only need to add on your class the name of the property you don't want to expose, but the problems comes when you want your class to exclude some properties for one feature and other properties for another feature, and you can't add fields and sometimes in MVC, the views need more fields that the ones provided by the model class and then you're gonna need to use ViewBag or something else. This approach is very handy for fast and smalls projects, but I still don't like to use ViewBag (For aesthetics reasons)

• Second approach (ViewModels): Is more work, and more time but at the end (again in my opinion) you get a cleaner and ordered code and you don't need to use the ViewBag, because you can have the perfect object to send to the view depending on what this View needs, so if you a have an object with different views, again depending on the needs, they could share the same ViewModel or they could have a ViewModel for each one. If you have a solution or a big web project, this approach is going to be very handy to keep an ordered code.

Let me know.