Question

I’ve just read about MVC3’s new CompareAttribute that you can apply to a model’s property to define another property that it should match – the classic use case is confirming email address has been entered correctly, or having a Password and ConfirmPassword field. I’ve run into a problem with trying to implement it in my own project.

We’ve got a fairly standard User object which, among other things, has these properties:

public class User {
    ....
    [Required, RegularExpression(RegularExpressions.Email, ErrorMessage = "Please supply a valid email address")]
    public string EmailAddress

    [Required]
    public string Password
    ....
}

I’ve then incorporated User and a couple of other objects that we need into a view model:

public class SignUpViewModel {
   ....
   public User user { get; set; }
   ....
}

Which, when passed to the form in the UI, allows the ModelBinder to run the Data Annotation validation for the User object as well as the other objects and primitive types in SignUpViewModel when the user submits the form. I was really pleased when this all “just worked” because it meant that we could define validation in just one place and not have too much work to do in persisting out to the database or map UI models to domain models etc.

Noticing that the Html.EditorFor(model => model.User.Password) emits an with the name set to “User.Password”, I added the following to SignUpViewModel:

[Required, Compare("User.Password")]
public string ConfirmPassword { get; set; }

but submitting the form now triggers a validation error along the lines of “Could not find a property named User.Password”. I was hoping that it would follow the same kind of convention, but it would appear not 🙁

I don’t really want to put ConfirmPassword into the User object as ConfirmPassword is purely a UI concern, and it seems wrong to have that in a domain object like that. I also don’t really want to flatten out the various objects within SignUpViewModel as that starts to feel like duplication of where validation rules are defined, and we’re trying to keep our code as DRY as possible.

Has anyone come across a way to get CompareAttribute working with comparing against properties of sibling objects rather than sibling properties as it would appear the attribute expects to?

Answer 1

Get rid of the User property on your SignUpViewModel and put the necessary properties from the User domain object on the SignUpViewModel.

You said you want your concerns separated, and having a domain object as a property on the view model is an example of not having your concerns separated.

This might seem like it could result in your writing more code, but look into a solution like Automapper to automate mapping your domain object properties to view model properties.