There are plenty of validation frameworks out there. I've worked with NHibernate Validators, Microsoft's Enterprise Application Blocks, and now Data Annotations. They primarily work by adding attributes to the properties in the class you want to validate.
How are they different?
Not very. The biggest difference between them is their syntax. I guess the Validation Blocks from Microsoft's P&P group have a lot of configuration options, but I haven't needed that on a project. The most prominent differences are in the attributes themselves.
You can probably make a case for Data Annotations having a slight advantage since it's going to be in the .NET base-class libraries. Easier to deal with assemblies installed in the GAC instead of the ones you have to drag around for each deployment.
How do you integrate them with MVC?
Each of these frameworks can be integrated with ASP.NET MVC. But the best validation call is one you don't have to explicitly make. Huh?
It's OK to call MyClass.IsValid() in a controller action, but if you can avoid it, I think you're better off. Otherwise, what happens if you forget to call it?
Instead, use a model binder that invokes the validation framework for you. This is how I am using the Data Annotations model binder with the MVC framework:
ModelBinders.Binders.DefaultBinder = new Microsoft.Web.Mvc.DataAnnotations.DataAnnotationsModelBinder();
Now this guy will intercept calls to your controller actions and reject invalid incoming view models. Here is a simple tutorial for using Data Annotations that goes into more detail.
How do you lay this out in the solution?
I have an Application Services layer that my MVC layer calls into. My controllers have constructors with an interface to an application service injected into them. My IoC container decides which concrete version of this application service interface to use at runtime.
Next, my Application Service layer has a DTO folder that holds all the DTOs (property-only classes) my views need in my MVC app. These are not my domain entities. There might be a lot of overlap with those domain entities, but these DTOs are just there for communication between the UI layer and Application Services layer. These DTOs are where I put my validation attributes.
So now I've got views that are tightly bound to the DTOs, which are owned in the Application Services layer. This allows strong typing of the view so I can use the DTO's properties as my view's model. This is handy for the Html Helpers to get design-time IntelliSense and compile-time checking.
What else can you do?
I haven't spent a lot of time looking into it, but xVal looks pretty strong for client side AND server side validation using Data Annotations and a couple other validation frameworks. It also lets you validate your business rules in your domain and throw an exception. I need to check into this more, because that sounds like the validation holy grail for validation to me: getting UI validation and business rule validation into a common format.
