IValidatableObject Validate() for different scenarios - asp.net-mvc-3

Question

I’ve been implementing IValidatableObject on Model entities, and using Validate(ValidationContext) to perform validation, often complex.
Can I use ValidationContext to distinguish different validation scenerios?
e.g. take for example a User model where I have 3 validation scenerios:
Sign up – I want to test an email is unique, and a small selection of required fields have been entered
Change details – Different email uniqueness check, bit more required details after sign up, not changing password here so it doesn't need checked
Change password – Only password field to validate
Is this a proper use for it, and if so how do I ensure the correct ValidationContext properties are set after a post and before Validate() is called? Or should I be taking a totally different approach?

Answer 1

The IValidatableObject is used to perform multiple validations against a single model. In your case you have a User model and you want to do three validations and you can do that perfectly by implementing the IValidatableObject in the User model.
The ValidationContext is not bringing much benefit (other than providing access to the context) since we can access all the properties directly in the Validate method.
An example of performing multiple validations related to the single model by IValidatableObject. (So what is the use of ValidationContext here?)
public class Party : IValidatableObject
{
[Required(ErrorMessage = "Start date is required")]
[FutureDateValidator(ErrorMessage = "Start date should be a future date")]
public DateTime StartDate { get; set; }
[Required(ErrorMessage = "Duration is required")]
public int DurationInHours { get; set; }
[Required(ErrorMessage = "No. of joinees is required")]
[Range(2, 10, ErrorMessage = "No. of joinees should be minimum 2 and not more than 10")]
public int NoOfJoinees { get; set; }
public bool Drinks { get; set; }
public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
if (StartDate.TimeOfDay > new TimeSpan(22 - DurationInHours, 0, 0))
{
yield return new ValidationResult("The party should not exceed after 10.00 PM");
}
if (NoOfJoinees < 5 && Drinks)
{
yield return new ValidationResult("Drinks are only allowed if no. of joinees is 5 or more.");
}
}
}

Answer 2

For my two cents worth I would say that your model is either in a valid state (applying all validation criteria) or it isn't. If, under certain circumstances, you don't want to apply a validation then I think you should really be using a separate model (ViewModel, actually).
In your example, I would create a RegisterViewModel for sign up and a separate EditUserViewModel for changing details. Each of these would then have their own validation and they would have a single responsibility.
Creating a fat model that you reuse in many different views is, imho, a bit of a code smell. I have a number of reasons for thinking this. Firstly, let's say that you have a single model that is used for all interaction with user data. It looks like this:
public class UserModel
{
public int UserId { get; set; }
public string Username { get; set; }
public string Password { get; set; }
public bool IsAdministrator { get; set; }
}
Later you decide to track the browser that was used during registration with the site. Where do you add that? It really has nothing to do with the user, so it shouldn't go on the UserModel model. If you had a separate RegisterViewModel you could modify it as needed when your registration process changes without concern as to how it would affect the other places it is used.
A more serious problem arises if, for example, you were using the above model with MVC's DefaultModelBinder. As described here, the user could create their own request and grant themselves administrator privileges even if you don't have the IsAdministrator field on the form (by exploiting a mass-assignment vulnerability). Again, if a separate ViewModel was used without the IsAdministrator property it would reduce the surface area for security holes.
The above is just an example, but I'm sure you get the point.