Validation strategies

I have a business model with many classes in, some logical entities within this model consist of many different classes (Parent-child-grandchild.) On these various classes I define constraints which are invariant, for example that the root of the composite should have a value for Code.

I currently have each class implement an interface like so...

public interface IValidatable
{
    IEnumerable<ValidationError> GetErrors(string path);
}

The parent would add a validation error if Code is not set, and then execute GetErrors on each child, which in turn would call GetErrors on each grandchild.

Now I need to validate different constraints for different operations, for example

1. Some constraints should always be checked because they are invariant
2. Some constraints should be checked when I want to perform operation X on the root.
3. Some additional constraints might be checked when performing operation Y.

I have considered adding a "Reason" parameter to the GetErrors method but for a reason I can't quite put my finger on this doesn't feel right. 开发者_运维知识库 I have also considered creating a visitor and having a concrete implementation to validate for OperationX and another for OperationY but dislike this because some of the constraint checks would be required for multiple operations but not all of them (e.g. a Date is required for OperationX+OperationY but not OperationZ) and I wouldn't like to have to duplicate the code which checks.

Any suggestions would be appreciated.

You have an insulation problem here, as your classes are in charge of doing their own validation, yet the nature of that validation depends on the type of operation you're doing. This means the classes need to know about the kinds of operations that can be performed on them, which creates a fairly tight coupling between the classes and the operations that use them.

One possible design is to create a parallel set of classes like this:

public interface IValidate<T>
{
    IEnumerable<ValidationError> GetErrors(T instance, string path);
}

public sealed class InvariantEntityValidator : IValidate<Entity>
{
    public IEnumerable<ValidationError> GetErrors(Entity entity, string path)
    {
        //Do simple (invariant) validation...
    }
}

public sealed class ComplexEntityValidator : IValidate<Entity>
{
    public IEnumerable<ValidationError> GetErrors(Entity entity, string path)
    {
        var validator = new InvariantEntityValidator();
        foreach (var error in validator.GetErrors(entity, path))
            yield return error;

        //Do additional validation for this complex case
    }
}

You'll still need to resolve how you want to associate the validation classes with the various classes being validated. It sounds like this should occur at the level of the operations somehow, as this is where you know what type of validation needs to occur. It's difficult to say without a better understanding of your architecture.

I would do a kind of attribute-based validation:

public class Entity
{
    [Required, MaxStringLength(50)]
    public string Property1 { get; set; }  

    [Between(5, 20)]
    public int Property2 { get; set; }

    [ValidateAlways, Between(0, 5)]
    public int SomeOtherProperty { get; set; }      

    [Requires("Property1, Property2")]
    public void OperationX()
    {
    }
}

Each property which is passed to the Requires-attribute needs to be valid to perform the operation.

The properties which have the ValidateAlways-attribute, must be valid always - no matter what operation.

In my pseudo-code Property1, Property2 and SomeOtherProperty must be valid to execute OperationX.

Of course you have to add an option to the Requires-attribute to check validation attributes on a child, too. But I'm not able to suggest how to do that without seeing some example code.

Maybe something like that:

[Requires("Property1, Property2, Child2: Property3")]

If needed you can also reach strongly typed property pointers with lambda expressions instead of strings (Example).

I would suggest using the Fluent Validation For .Net library. This library allows you to setup validators pretty easily and flexibly, and if you need different validations for different operations you can use the one that applies for that specific operation (and change them out) very easily.

I've used Sptring.NET's validation engine for exactly the same reason - It allows you to use Conditional Validators. You just define rules - what validation to apply and under what conditions and Spring does the rest. The good thing is that your business logic is no longer polluted by interfaces for validation

You can find more information in documentation at springframework.net I will just copy the sample for the their doc to show how it looks like:

<v:condition test="StartingFrom.Date >= DateTime.Today" when="StartingFrom.Date != DateTime.MinValue">

<v:message id="error.departureDate.inThePast" providers="departureDateErrors, validationSummary"/>

</v:condition>

In this example the StartingFrom property of the Trip object is compared to see if it is later than the current date, i.e. DateTime but only when the date has been set (the initial value of StartingFrom.Date was set to DateTime.MinValue).

The condition validator could be considered "the mother of all validators". You can use it to achieve almost anything that can be achieved by using other validator types, but in some cases the test expression might be very complex, which is why you should use more specific validator type if possible. However, condition validator is still your best bet if you need to check whether particular value belongs to a particular range, or perform a similar test, as those conditions are fairly easy to write.

If you're using .Net 4.0, you can use Code Contracts to control some of this.

Try to read this article from top to bottom, I've gained quite a few ideas from this.

http://codebetter.com/jeremymiller/2007/06/13/build-your-own-cab-part-9-domain-centric-validation-with-the-notification-pattern/

It is attribute based domain validation with a Notification that wraps those validations up to higher layers.

I would separate the variant validation logic out, perhaps with a Visitor as you mentioned. By separating the validation from the classes, you will be keeping your operations separate from your data, and that can really help to keep things clean.

Think about it this way too -- if you mix-in your validation and operations with your data classes, think of what are things going to look like a year from now, when you are doing an enhancement and you need to add a new operation. If each operation's validation rules and operation logic are separate, it's largely just an "add" -- you create a new operation, and a new validation visitor to go with it. On the other hand, if you have to go back and touch alot of "if operation == x" logic in each of your data classes, then you have some added risk for regression bugs/etc.

I rely on proven validation strategy which has implemented in .net framework in 'System.ComponentModel.DataAnnotations Namespace' and for example used in ASP.NET MVC.

This one provides unobtrusive way to apply validation rules (using attributes or implementing IValidatableObject) and facilities to validate rules.

Scott Allen described this way in great article 'Manual Validation with Data Annotations'.

• if you want to apply validation attributes on interface then look at MetadataTypeAttribute
• to get better understanding how it works look at MS source code