MVC3 Service Layer Validation. Returning Exception, Custom Object, Model State Dictionary?

Just curious on your thoughts or experiences around service layer validation.

I have to process fairly standard validation such as "object with name property doesn't already exist", but I wasn't sure how to return these validation failures back to the controller.

My initial thought was to implement a standard List<ValidationError> but I've seen it done each and every way so was curious the pros/cons of each.

Thanks for any in开发者_开发技巧put.

---

If you go with System.ComponentModel.DataAnnotations entries you can (as you seem to know) decorate your properties with required and many more tags

public class Person
{
    [Required(ErrorMessage="object with name property doesn't already exist")]
    public string Name { get; set; }
}

although I personally use ViewModels rather than exposing domain mdoels to the view, your controller action can now do something like:

[HttpPost]
public ActionResult SavePerson(Person model)
{
    if (ModelState.IsValid)
    {
        // your model validates - do things

        return RedirectToAction("success view here");
    }
    return View(model);
}

This is one of the standard 'post' handler patterns in MVC. This is the simplest path to getting your object model validating in my opinion.

From there, there are a few other options - your domain object can implement IValidatedableObject and you can yield return the errors (see http://buildstarted.com/2010/09/20/mvc-3s-ivalidatableobject/ as an example).

I'd recommend not mixing the two though, as if you are using dataannotations and have even a single invalid property, the IsValid method on IValidatableObject will not be called.

From there, there's lots you can do with custom validation attributes (the extended version of IsValid seems to give you more flexibility http://msdn.microsoft.com/en-us/library/gg480674%28v=vs.98%29.aspx)

Hope some of the above helps - once you get past the basics there's a lot you can do with it and things like client validation of custom attributes etc. are all fun.

Cheers, Terry

[edit to add:

After re-reading your post, it may be that you want to only validate at the service layer? If so, I've used the following approach:

public void Setname(string newName)
{
    Validator.ValidateProperty(newName, new ValidationContext(this, null, null) { MemberName = "Name" });

    Name = newName;
}

obviously your Name property would need a { get; private set; } for this, though you could always add the Validator.ValidateProperty into an extended setter for the public property either.

]

---

On a new project I'm working on (first time mvc) I've been using the ms code contracts (which throw exceptions) and do all the validation on my domain objects themselves. For things that can't be validated there (such as validations that require database access) I validate in my services and throw exceptions. Additionally like the poster above I have whole separate view models for everything that have data annotations validators on them. The exceptions bubble up and I catch them in the controller and append to the ModelState. There's a lot of overlap with those and the view model validation but it's not much extra effort and allows me to vary the validation per view and yet still have the "core" validations be required.

The book pro asp mvc 2 has another nice way - write a class that inherits Exception and contains a collection of errors. Then you do your validations, add to the collection then throw the exception then he catches it in the controller and copies over to ModelState. This method will let you catch ALL the errors in one exception instead of just one at the service layer.