Question

We are using a validation framework (something we have cooked up ourselves) which allows us to do validation assertions on objects.

string Validation<T,U>(T obj, Func<T,U> selector, Validations.IsNotNull,
                       string failureMessage) 
       {
           var propertyToBeValidated = selector(obj);
           // Do validation here, if it fails, return failure message
       }

The problem with this is:

• The message is mandatory. We cannot auto generate a meaningful message looking at the selector.

The other option is to change the signature of the above method to:

string Validation<T,U>(T obj, Expression<Func<T,U>> selector, 
                       Validations.IsNotNull, string failureMessage = null) 

In this case the failure message is optional and we can get the property name from the expression tree.

However, this requires an Expression.Compile before the selector can be invoked and slows down things by 3 orders of magnitude. As of now the messages are mandatory but as the validations are somewhere else, refactoring requires changing the validation messages too.

What would you suggest:

• Change signature and accept expressions. Cache the compiledd expressions if need be and auto generate the messages. Is a message is provided, use that instead.
• Changing messages by hand is an acceptable overhead as you have a good test coverage. Leave the signature as is and avoid the additional complexity and the performance hit.

Edit: We are using this validation framework accross multiple layers. In out controllers for validating input parameters, in our services for validating incoming requests and in our integration tests for validating state of objects after some operations. The cost of expression.Compile is insignificant compared to some of these costs, but not insignificant compared to datbase access, etc.
Thanks

Answer 1

We concluded that for us it made the most sense to use an Expression.
The overhead of the DB and WS calls was far greater than this.