Validation Result Practies. Boolean or Count?

Over a few years, I have have written a few validation classes and have always wonder what people thinks is the best way of handling them.

I've seen and done each of the following and am curious to your know opinions and why.

Scenario 1, Message Counting

class ValidationClass1
{
    public List<string> ValidationMessage { get; set; }

    public void Validate(x)
    {
        // pseudo-code
        if (!rule_logic1)
        {
            ValidationMessage.Add("Error in logic 1");
        }
        if (!rule_logic2)
        {
            ValidationMessage.Add("Error in logic 2");
        }
    }
}

Scenario 2, Returning an Object or Tuple

class ValidationClass
{

    public Tuple<bool, List<string>> Validate(x)
    {
        List<string> ValidationMessage = new List<string>();
        bool passed = true;

        // pseudo-code
        if (!rule_logic1)
        {
            ValidationMessage.Add("Error in logic 1")开发者_如何学C;
            passed = false;
        }
        if (!rule_logic2)
        {
            ValidationMessage.Add("Error in logic 2");
            passed = false;
        }

        return new Tuple<bool, List<string>>(passed, ValidationMessage);
    }

}

In Scenario 1, the ValidationMessage list could be the return type as well. Regardless, calling code would have to check the count property of the list to see if the data passed or not. If it was only a singular rule, the returning string length would need to be checked via string.IsNullOrEmpty(x).

In Scenario 2, a custom object or tuple would be the return type so that the calling code would have to have knowledge of the returning code and evaluate a boolean property to see if it passed and then the validation messages.

So, in your opinion, which way do you prefer or if you have a different preference, I'd be curious to hear that as well.

Thanks

I've used a variant of Martin Fowler's Notification Pattern to handle validation and associated validation error messages.

Here is the specific class that might address your "Boolean or Count" question:

class Notification...
    private IList _errors = new ArrayList();

    public IList Errors {
      get { return _errors; }
      set { _errors = value; }
    }
    public bool HasErrors {
      get {return 0 != Errors.Count;}       
    }

His pattern uses more granular members to indicate whether general validation failure has occurred ('HasErrors' which returns a boolean based on 'Errors' collection count) and what specifically has failed ('Errors' collection from which you can derive a count) The actual 'Validate' code that runs the validation is a separate method altogether (found on the business/domain object that requires validation).

The pattern might be a bit out to date (including my own previous implementation) but it does expose you to some alternatives and can give you some ideas to build on.

If you implement the IDataErrorInfo interface, you can automatically bind the validation to controls (both Winforms and ASP.NET) without any additional code.

At first glance I'd say the first option is more readable, but then when you think about it the second seems more appropriate.

It's probably a very subjective matter, but here's what I think.

In the first version, the consuming code has to do a "Count" which I believe to be more resource consuming than simply checking a boolean value (although the difference is probably neglectable in every way).

However the second version does have a more "clear" indication that something went wrong. Validation is a test and "passed=false" indicates the test failed whereas in the first version there is no such indication.

In both versions the consuming code requires knowledge of the fact that in version 1 -> Count > 0 means failed and in version 2 passed = true means failed.

Personally I'd collect the validation failures as you have but then throw an exception and pass that list as an argument to that exception. As a result the consuming code is forced to deal with the problem.

But once again, my opinion is purely subjective.

For validation of objects, I have recently gone the way of using attributes, where the validation rules and associated error message are encapsulated in attributes that implement an IValidationAttributeinterface, and the object 'under validation' is passed into a validator object that uses reflection to pick up all implementations of 'IValidationAttribute' and calls the validation logic within.

The Validator object accepts one object, or a lists of objects, performs the validation and returns a ValidationResult containing a result and errors.

I am not sure if this would help, your needs are unclear, but I find it to be as very fast, clear, and concise way of performing validation on objects with properties.

Broken Rules collection for complex validations, definitely.