Fubu’s Validation Story

We set out to accomplish a few things with the new FubuValidation bits. After some brainstorming, we had ideas that aligned with one of the fundamental philosophies of Fubu: don’t get in the way. More specifically, eliminate repetitive code and restrict the surface area as much as possible. We’ve completed the initial draft and I wanted to take the time to write about it a little.

Topics

1. Validation Rules
2. Validation Sources
3. Validation through attributes
4. DSL and Validation query
5. Notification

Validation Rules

Let me cover the basics first. As the name suggests, validation rules are the actual rules themselves that execute against your objects. Given the queryable nature of validation (more on this later), we also added a policy-like method to ensure that we’re only applying the rule against the appropriate properties. The interface is fairly straight-forward:

Validation Source

Validation Sources have one primary responsibility: provide validation rules. You can have multiple sources registered with Fubu or just one, it doesn’t really matter. Because the sources are responsible for creating the rules for a particular type, caching and overall lifecycle management needs to be handled by each source. Some rules need to be determined on the fly each time while others do not. Leaving that in the hands of custom sources gives us and you more flexibility. Again, this interface is fairly straight-forward:

Validation through attributes

Out of the box, FubuValidation gives you a few validation options:

• GreaterThanZero
• GreaterOrEqualToZero
• Required
• MaximumStringLength

One way to get at these (and possibly the easiest if you’re just getting started) is to annotate your properties with the respective attributes (i.e., GreaterThanZeroAttribute). Those attributes are capable of creating the proper validation rule that they represent which a built-in validation source picks up by default. Actually, under the hood there’s a concept of an IValidationPolicy that makes our conventional validation possible but more on that later.

DSL and Validation Query

As the name suggests, the Validation Query gives you information about all the rules that you have configured. It gives you quite a few options for querying:
Currently, the Validator class allows you to bootstrap FubuValidation into a static façade so that you can register the query into your appropriate IoC container. However, the ValidationRegistry from which you derive from to bootstrap is what creates the query so you can bypass that piece if you’d like. Here’s an example of a registry:

You may note the use of “Strategy” here. Most rules that target an individual field have the same basic boiler plate code so the baked-in rules all share a base class: FieldRule. The logic for actually evaluating the validity of the value is delegated to an IFieldValidationStrategy implementation.

Notification

I’m not the first to discuss this pattern. Fowler did a good job at cataloging it and Jeremy’s talked about it for years so I’ll leave it to them to explain this in detail. Rules take in a notification while performing validation and register error messages against it.

Up next: Integration FubuValidation and FubuMVC. I’m still trying to get to that post tonight but we’ll see where the night takes me.