Why use fluentvalidation instead of ASP.NET MVC validation

Question

In which circumstances would you choose FluentValidation (FV) over the ASP.NET MVC 3 way?

What are the advantages of FV over MVC? I realise that with the latter we have to write much more code and can litter the code with Data Annotations. Moreover, it would seem to be easier to write custom validation using FV than MVC. However, with MVC it is possible to make use the data annotation and plug jQuery validation in.

So what in your view would make you choose one over the other? Are there circumstances where you would even use both?

Partition

Answer 1

Fluent validation is one way of setting up dedicated validator objects, which you would use when you want to treat validation logic as separate from business logic. The aspect-oriented programming (AOP) paradigm enables separation of cross-cutting concerns within a system, and validation is one such concern. Separating validation helps clean up your domain code and make it more cohesive, as well as giving you a single place to look for validation logic.

MVC annotation-driven validation is a very 'cheap' way to get some basic validation into an application, without going to the hassle of creating dedicated validator objects, creating a validation system which organizes them and plugging it all together. It's very easy to set up, but can make your domain objects less clean.

For small systems where all the validation logic can be handled using annotations, I would recommend just using annotations, because they're so easy to set up. For larger, more complex systems, I would recommend separating the validation concern using validator objects.

I personally like to use both approaches: add validation attributes to ViewModel classes (which means the annotations don't clutter up my domain objects), as well as having dedicated validator objects within my domain layer. This is a small amount of duplication, but using annotations is so quick and easy, I find it worth the extra maintenance cost.

Knurl

+1 especially for the third and fourth paragraphs. I often see people over-complicating things and in the real world (where one actually has to deliver something at some point) it's important to make the solution fit the problem. Yours sounds like a laudably pragmatic approach. – Messier

Point taken. However, when you say that "MVC annotation-driven validation is a very 'cheap' way to get some basic validation into an application", I assume that you are talking about out of the box validation i.e. NOT custom validation. Otherwise, we must be doing something wrong as it's taking us time to get the custom validation going in the MVC way as provided in the link in the OP. In the latter link, there is this separation of concerns that you talk about although of course there are data annotations but the custom validation class itself is separate. – Partition

@Partition - I did mean the built-in validator types, yeah - although I assume once you get over the hump of working with custom validators they'd also be pretty cheap to use. FV gives you "a validation system which organises [validators] and plug[s] it all together" via the class-level Validator attributes, which reduces hassle; I'd still say the driving factor in deciding which route to take should be the complexity of the validation required. – Knurl

Thank you for your answer. We started out with FV but then I made the decision to go and use MVC validation because we require client side validation as well. It might be one of those where only time and experience will tell what is right and what isn't. – Partition