In a previous post I described a "ValidationResult" class we've created here at work for "lazy validation", where the "IsValid" property is a nullable boolean and is set to null if the code can't determine its value without the user's help.

Earlier this week we were working on a method that should create a row in a database table and return the identity (a Guid) of the row it just created. However, we also wanted to return a ValidationResult (true if it succeeded, false with an error message if it failed). We started out by using an "out" parameter, like this:

public ValidationResult CreateFoo(int someProperty,

 string someOtherProperty, 

 out Guid id)

This design, however, had a few problems. Firstly, we're trying to unit test everything in this project, and our mocking framework, Moq, can't mock "out" parameters. I don't think this limitation is specific to Moq, but it was enough to make us consider a different approach. Secondly, FxCop actually complained that "out" parameters should be avoided, as per this rule.

So we needed a way to return two things: the success/failure result of the call, and the identity of the created item. Enter ValidationResult<T>!

With this new class, we have an extra bit of "payload" data that we can return along with the validation result. So now our method signature looks like this:

public ValidationResult<Guid> CreateFoo(int someProperty, 

 string someOtherProperty)

... and it has some code like this to return its stuff:

var vr = ValidationResult<Guid>.Success;
vr.Data = (Guid)param.Value;
return vr;
Pretty handy! Now we can test it and we're down one FxCop warning!