Asp.NET MVC - DataAnnotations and ModelState.IsValid too invasive into the domain model?

Question

I'm learning ASP.NET MVC from the book Pro ASP.NET MVC 4 (which I love so far, by the way).

I'm still in the beginning chapters and it's showing me the System.ComponentModel.DataAnnotations namespace attributes, how to sprinkle my model class with these annotations, and then how to use them to check if the model is valid (ModelState.IsValid in the Controller).

For example:

public class GuestResponse
{
    [Required(ErrorMessage = "Please enter your name"]
    public string Name { get; set; }
}

...

public ViewResult RsvpForm(GuestResponse guestResponse)
{
    if(ModelState.IsValid)
    {
        return View("Thanks", guestResponse);

    }

}

There are a couple things about this that make me uneasy.

1. Why do I want a bunch of attributes littered throughout my domain model? I like my domain model pure and free from any stuff that is implementation specific, and any real world model would be too complex to just use declarative validation like this.
2. Aren't the ErrorMessage parameters of the validation attributes somewhat View related? Doesn't something like that belong in the UI layer? For example...what if due to space constraints I want the mobile version to instead of saying "Please enter your name" say "Name required"? But here it is in my model!
3. Why do I want to use ModelState.IsValid to determine the status of the model? Shouldn't the model tell me? I understand that ModelState is making use of the DataAnnotations attributes that are in my model, but this seems like it would only work for very simple models. A more complex model might not even have a valid/invalid state, it might just have various stages and states. I'm sort of rambling here, but I don't like the idea of declaratively saying what makes my model valid or invalid.

Any advice, reassurance, or validation of these thoughts would be appreciated.

Answer 1

Here are my answers to your questions:

1) Why do I want a bunch of attributes littered throughout my domain model? I like my domain model pure and free from any stuff that is implementation specific, and any real world model would be too complex to just use declarative validation like this.

You absolutely don't want this. What you want is to have a view model which is specifically designed for the purposes of your view. It is this view model that will contain the data annotations, not your domain model. Then the controller will map between the domain model and the view model and will pass the view model to the view. Think of the view model as the projection of one or more domain models. In order to simplify the mapping between your domain and view models you may checkout AutoMapper. The basic rule of thumb is that a view should not be aware of your domain models.

2) Aren't the ErrorMessage parameters of the validation attributes somewhat View related? Doesn't something like that belong in the UI layer? For example...what if due to space constraints I want the mobile version to instead of saying "Please enter your name" say "Name required"? But here it is in my model!

Completely agree with you. That's the reason why you should have a view model class which is specifically designed for the purposes of the view.

3) Why do I want to use ModelState.IsValid to determine the status of the model? Shouldn't the model tell me? I understand that ModelState is making use of the DataAnnotations attributes that are in my model, but this seems like it would only work for very simple models. A more complex model might not even have a valid/invalid state, it might just have various stages and states. I'm sort of rambling here, but I don't like the idea of declaratively saying what makes my model valid or invalid.

Once again I agree with you. Declarative validation (such as what you get out of the box with Data Annotations) works great for Hello World type of applications but once you start writing real world applications with complex validation rules you quickly realize that the declarative approach simply doesn't cut the mustard. It is for this reason that I use FluentValidation.NET. It provides you with a very nice and fluent syntax to express arbitrarily complex validation rules, it integrates easily with ASP.NET MVC and allows to unit test your validation rules in complete isolation.