Starting an open-source rewrite of a validation microframework

A few years ago I gave birth to the validation framework that I felt was uniquely capable of addressing complex validation scenarios I’ve come across. The following is a brief insight into how it came to be and where it’s at.

If you’re familiar with DDD, you’ll remember the pattern for expressing business rules via specifications. While simple and powerful, I found it to be insufficient: what we want to know in the real world scenarios is not only if something satisfies a given criteria, but also what does it mean if it does or doesn’t.

Here’s an example, given an entity E you need to ensure that a field X is of certain length. You can have a rule, here expressed as  the function:

 e => e.X.Length < MAX_LENGTH

Great you’ve got the logic, nicely encapsulated inside your domain. It can be referenced by name and it’s testable. Now what? What are we going to do with the fact that the rule evaluated to false?

What all of it lacks is context. What is the context of this evaluation? Why are we doing this? To throw an exception? No, we need more information even if we throw an exception and even having composable rules (named Specifications by Evans) isn’t going to help us tell the user what do we think is wrong.

Here’s an example of the context: a user is entering some text in a webform into the field X. Joel Spolski will have a field day ridiculing your UX, but you want to tell the user that what he’s entering is too lengthy.

Another example using the same rule but in different context: your API is called to import list of Es and you want to collect all the errors to respond with once you’re done processing the batch.

We most certainly want to reuse the rule, but what we do with the outcomes of the evaluation is completely different. How about an entirely different UI? Or an another application that makes use of your domain internally? They may all want to do something different with the outcome!

I dislike the idea of validation as a cross-cutting concern (addressed with attributes) for the same reason – it makes no effort to incorporate the context.

Here’s another example of the context: Say the entity E contains two complex properties of the same type:

class E { public A A1; public A A2; }

which contains property B:

class A { public string B; }

And your rule is to permit value “b1” for A1.B property and “b2” for A2.B property. You see the context (it’s the overall path to the property B), but your attributes – don’t. It’s very hard to make sense of things looking from inside out.

This leads me to my proposition: The validation is best performed and described from the outside, looking in.

Everything is easier as you have the access to all sorts of contexts: use-case, user, dependencies, etc. It’s easier to implement and it’s easier to understand.

So what do we need, other than the rules?

We’ll need to redefine what Specification is. We’ll use Specifications to associate Rules with outcomes.

We’ll also need to express Interpretations of the rules in a manner that would let us carry out contextual parametrization (such as reporting the offending value, constraints of the rule itself, localization, etc).

For the maximum flexibility we’ll need factories of Interpretations and Actions to carry out given an outcome, enter: Bindings.

The framework was very successful and ended up used in several Novell products (of PlateSpin fame) and I’ve decided to do an open-source rewrite. That’s all there is to the microframework I posted on github.

At the moment, I’ve got the basics setup: the build, the tests and the major components. The library is .net portable, so I’d like to have samples in MVC, WPF, Silverlight and WP.

Starting an open-source rewrite of a validation microframework