A Flexible Guard Class

Writing a guard class that implements parameter checks seems to be simple – but can become complex if you want some additional features (e.g. logging for rule violation, custom rules etc.). Also code contracts may be too much to learn/invest for your team/project.
The guard class presented in this sample project can easily be implemented, supports central and per project definition of validation rules, enables you to add aspects like logging and implements debug-only checks to perform more restrictive checks while running a debug build.
I’ll start with the sample project, which is quiet simply:

As you can see we are calling a method performing an action (writing to the console) based on the value of a parameter – so the parameter must be checked for validity.In this sample we check the parameter with two asserts per parameter. The first assert for the parameter “message” checks for a rule set (a list of predefined rules), the second for a “custom logic”. The checks of the second parameter are very similar.
The For method of the Guard class simply initializes a generic data-checking class CheckData<TData>, which hosts the Assert methods. The parameter is the data to be checked, but it’s specified as a Lambda expression, so the For method can get the parameter name without specifying it as a string:

This way we encapsulate the statement that evaluates the CheckExpression method which is Func<TValue, bool> as defined in the generic parameter of the RuleBase inheritance. We need different inherited classes in order to support rules that do accept different counts of parameters.The implementation of InvokeInternal does accept a function that returns a Boolean instead of accepting the Boolean directly. This enables us to execute logging before executing the check expression, implement a generic exception handler for executing all rule checks etc.
A second rule class has been implemented using a different check function signature:

As you can see, the only difference is the count of parameters for the check expression, which is of type Func< TValue, TCheckParameter, bool > – until now we didn’t implement any check logic. The Rules class does define the predefined check logic. Here is one example:

So each “predefined” rule is a (sometimes generic) static method that returns a class instance that inherits from RuleBase and implements AssertFor (which is called by the Assert method of CheckData). Unfortunately there are no “generic properties”, so we cannot use that – which would have allowed us persisting the rules into XML and load them from a file.
To enable in place definition of check expressions, I’ve added an overload of the Assert method accepting a Func<TData, bool>:

In the sample project, there are more overloads, so you can omit the message, use different rule types (with different parameters) etc. – including an overload that accepts IEnumerable<Rule<TData>>, so that you can define rule sets that can be managed in a central way (e,g, if you want to check all incoming strings on the service boundary for something special).
Another little assert I’ve added is being called like this:

Guard.For(() => myMessageOne).Assert();

Whoups – where’s the rule? The magic in this case is done by registering the rules for a specific type elsewhere, so that each time an Assert is called without specifying a rule, the default rules of the type (MessageOne in this case) are applied. The Assert statement is like this:

This enables us to specify a list of rules as the default specification of a data type (business entity).
Hope this guard class example will help you with some problems it will solve.
For a great introduction into guard classes also have a look at Posting Guards: Guard Classes explained (AJ’s blog)
I’ll integrate the complete source code with 100% covering unit tests and a little sample method to my project at CodePlex: Sem.Sync – and I promise to do it in a way that you will be able to use it without using the rest of the project 😉 . A draft version can be downloaded from here.