Should validation rules always be enforced at the model level?

Question

With the new ASP.NET MVC 2 validation features, we can decorate the properties of our domain model objects with DataAnnotations attributes that describe criteria for valid values. The DefaultModelBinder knows about this and populates ModelState.IsValid accordingly before a controller action is invoked. Since the validation rules are defined within the domain model, this is regarded as model-level validation. Scott Guthrie writes:

The benefit of implementing the rules within our Person object is that this will ensure that the validation will be enforced via any scenario within our application that uses the Person object [...]

Strictly speaking, the rules are not really enforced in my opinion, since all the action methods need to check the ModelState.IsValid property and act differently depending on its value. Also, although the rules are defined in the model, they are applied in the presentation layer since that's where all model binders live. But I guess this is just me being picky with the choice of words (or me just being plain wrong).

However, what about enforcing the validation rules at the domain model level? Steven Sanderson uses this approach in a post about the xVal validation framework where he writes:

Now, the model tier enforces its own validity by refusing to place bookings that don’t meet all validation and business rules.

In his example, the "booking manager" (which lives within the model) throws a special business rule exception when consuming code tries to place a booking that is invalid. Thus it is impossible for the consuming code to place an invalid booking, regardless of whether it checked the validity of the booking beforehand (through ModelState.IsValid or some other custom construct).

So my question is:

Assuming that there are validation rules defined at the model level, should they also be enforced within the model?

(Note that I'm really new to the concept of domain-driven design, so please bear with me if I haven't used precisely the correct terminology.)

Answer 1

Assuming that there are validation rules defined at the model level, should they also be enforced within the model?

Yes. If you provide a way for the rules to be short-circuited, then they will be. Maybe not by you, and maybe no time soon, but surely by other developers in x weeks/months/years in the future.

Plus there's always the human error element - maybe one day when you're tired or coding late at night, you incorrectly read this validation flag and are actually letting records through that don't validate. (Don't scoff, I've done it myself!)

I now always make sure a record cannot get through to the database without being validated by the model.

Answer 2

I'm not too sure about this DataAnnotations either. But it seems they should work everywhere, whether the model is in ASP.NET MVC project or not and used from there or not. Because DataAnnotations are part of System.ComponentModel.DataAnnotations. I find this especially useful since I have all my models defined in separate projects, outside of the core MVC project in my VS solution.

Answer 3

DataAnnotations are a useful feature of ASP.NET MVC 2, it really does provide a nice cheap way to get both server-side and client-side validation. Though, you're right to point out a major weaknesse. But I also don't think enforcing validation via the model is a sure thing either; I see two issues:

Issue 1: how are you doing to enforce this? You can put all kinds of validation on your constructor, and your setters, etc..., but you can easily run into issues where you need to circumvent those rules. A good example is serialization; while you can generally work around it, sometimes during the deserialization of an object you just need to allow the object to be in an invalid state for a moment. Another example would simply be an extremely complex hierarchical model (e.g., parent requires a child and that child requires a parent, obviously you have a chicken-and-egg problem since you can't construct them simultaneously).

Issue 2: what about validation rules at a higher level (e.g., usernames must be unique)? You can't have these rules in the Model.

At the end of the day you should strive to make your code as clean and intention revealing as possible, and keep things well-tested. I have yet to see any model based validation that really fully protects the integrity of your data 100% of the time. Even if a user doesn't break your model, another developer eventually will.