Not using Form Models

Mar 8, 2011 at 9:21 AM

For editing entities in web project you use domain models, which are not safe.

Better practice would be to use Form models for editing purposes. It will prevent binding of all attributes of domain model.

For example, in ProfileController while editing I was able to inject hidden input tag in form and set HasRegistered attribute to True, while in domain it was False. As result, I changed it on submitting.

Mar 26, 2011 at 9:29 PM

I agree. It this is supposed to be best practices, this is a big no no.
View Model is therefore recommended practice.


May 4, 2011 at 6:49 PM


I'm assuming by "Form models" that you mean the application should have a view model specific to each form so that only the intended data is sent to and from the client.  Yes, we agree that this a good practice. 

Within the MileageStats application, we likely didn't consider this in depth for a few reasons. 

  • The services model is integrated with the view models.  It is built to be round tripped and provides server and client validation.  The HasRegistered attribute is one of the few cases where the entire domain model isn't round tripped to the client. 
  • There is limited risk since we only have a single authorization level after authentication (users are only able to manipulate their own data).  
  • The business services translate between the domain and data models, certain operations will ignore any additional properties (registration and profile happen to call the same controller action).

Reasons aside, we want to provide the right guidance and will address this in the guidance documentation.  Depending on the project timeline we will also consider addressing this issue in the code.

Thank you very much for pointing this out,

Geoff Cox
Southworks, Inc.
on behalf of Microsoft Patterns & Practices