MrKWatkins

Fluent Argument Validation Part 2 - The Approach

Posted at 24 June 2009 21:00:00 in C# | Fluent | Performance | Validation

As covered in part one I have decided to create a fluent library for validating arguments as I wasn't happy with ones currently available. But what exactly do I want?

To explicitly state that we are validating arguments
To validate that the user has not passed in a null or empty parameter name
To specify the argument and parameter name once and then be able to chain a series of validations
To not have to specify when to validate (e.g. with a .Check() or .Validate() method)
To stop the user chaining non-sensical validations together, where possible

Which gives a syntax something like this:

public static void SomeMethod(string stringValue, int intValue)
{
    Validate.Argument(stringValue, "stringValue")
        .IsNotNull()
        .IsNotEmpty();
        
    Validate.Argument(intValue, "intValue")
        .IsPositive()
        .IsLessThanOrEqualTo(5);

Why have I created a class called Validate with a property called Argument rather than a class called ValidateArgument? This is so I can expand the library to validate other things apart from arguments, all from the same starting point. For example I could expand it to do things like:

public static void SomeOtherMethod<TEnum>(TEnum enumValue, string directory) where TEnum : struct
{
    Validate.TypeParameter(typeof(TEnum), "TEnum")
        .IsEnum();
        
    Validate.Directory(directory)
        .Exists()
        .IsEmpty();

So, how am I going to actually code this thing? Well if I'm going to chain these validations together then I will need to store the argument and parameter name somewhere. There are a two obvious ways to do this:

Store them in a field somewhere. This would need to be a thread safe; threading issues are hard enough to debug at the best of times without argument validation giving you apparently false exceptions...
Create an object to hold them in. However the methods in the chain will need to change depending on depth; we don't want to allow two calls to IsNotNull() in a row for example. Therefore we are either going to need to create a new object when the methods in the chain change or create one object that implements multiple interfaces explicitly and then cast it to a different interface when then methods in the chain change. And should our objects be structs or classes?

Which way is best? Are any methods intrinsically worse for some reason? Performance is a good reason. Whilst I'm a firm believer that you should get you application working and performance enhance after (slow code is better than no code!) I also think prototyping is a good idea. If we can do a simple test at this stage then we might well find out that one approach is fundamentally slower than the others.

So I've knocked together a simple application to test each method and see which is quickest; feel free to play with the source code. It measures how long it takes to validate a string argument is not not null and not empty 25,000,000 times, compared against two not so fluent methods. On my PC the results are: (times in seconds)

Method	Description	Debug	Release
Not as fluent, single method	Does both validations in a single call, i.e. `IsNotNullOrEmpty(argument, parameterName);`	1.74	0.39
Not as fluent, separate methods	Does one method call for each validation, passing in argument and parameter name to each method.	2.66	0.69
Create multiple classes	Creates a new class each time the methods in the chain change.	6.05	2.47
Create single class	Creates a single class and casts it to a new interface each time the methods in the chain change.	3.00	1.00
Create multiple structs	Creates a new struct each time the methods in the chain change.	3.70	1.75
Create single struct	Creates a single struct and casts it to a new interface each time the methods in the chain change.	3.73	1.86
ThreadStatic store	Stores the argument and parameter name in fields marked with the ThreadStaticAttribute; uses extension methods to build the chain.	7.32	4.01
ThreadLocal store	As above but uses a named data slot on the current thread to store the argument and parameter name.	80.97	80.08
ContextStatic store	Stores the argument and parameter name in fields marked with the ContextStaticAttribute. Not at all suitable for the job... It's here for no other reason than I'd not heard of this attribute until recently and wanted to see how it performed...	50.25	51.93

So it looks like the single class approach wins. A few things to note though:

This test is for two chained calls; I suspect we might find a using structs is faster for a single call. But then one of the points of this library is that you can chain methods... Besides I seem to spend half my life validating strings for not null and empty so I reckon my code will be using chains of two or more items quite a lot...
Not as fluent, separate methods is fairly close to the single class approach. This might be because it has to validate that the parameter name is not null or empty twice whereas the single class approach only has to do it once.
Although creating multiple structs is quicker than multiple classes (as you'd expect; in the current .NET implementation local structs are allocated on the stack so there is no need to garbage collect them and perform all the tracking that goes with that) creating a single struct isn't. This is due to boxing. Interface methods are defined as being virtual but structs simply don't have it in them to handle that (they're missing a vtable to lookup the virtual methods) so they get boxed, giving us the performance hit.
The CLR team have clearly optimised the crap out of ThreadStatic fields given that they're 20 times faster than using named data slots.

So I have an approach. In the next post I'll start to look at implementing it.

Fluent Argument Validation Part 2 - The Approach

Archive

Tags