Question

Right now the application being built by our team uses the built in MVC attributes and a few home baked ones to validate the View Models. Because of best practice design principles, we have placed those same rules in the Logical Layer. This has unfortunately caused duplication of validation code.

In MVC3 at least, if JavaScript is disabled, these same attributes will still perform the validation they are meant to, so transforming a View Model in to a DTO and asking the Logical Layer to validate it is not an option because this process would have already been done by the framework.

I have not found the following SO post to be of any help. I have used MS Enterprise Library and the API did not sit well with our team.

Good practices for avoiding validation logic duplication when working with both domain objects and view models in ASP.NET MVC

I’m thinking that the best way to do this is to have the validation attributes bound at runtime to specific properties and have a dependency injection container do this. Is this possible or is there a different approach we could take?

Answer 1

You are asking for multiple validation types to be performed here.
You want client validation (it seems) and some other business validation layer.

If thats the case the only choices as I see it are:

1. duplicate the code (ya I know Im listing options)
   1a. use data annotations on your objects for client validation. Business layer validation happens however you define, and separate as a final check. If you use for instance the entity framework’s fluent API this is a standard route.
2. client side validation is just that – helpers for client side. domain validation will happen upon save. This is ideally the more powerful approach, but isn’t as friendly when your domain objects don’t match property names on your view models, so you need to map domain errors to view model property errors which normally isnt too bad but can get iffy.
3. implement IValidteableObject (and rid of client validation). This validation logic is then called from your logical layer and the model binder.
4. You can inject code for validation, but its not pretty and Im not sure how reusable it is outside the MVC validation route.

There may be other ways beyond this, but those are the main options as I see it.