Validation by Convention: A brief introduction

A little history

The ProAce team has been a little quiet lately. It’s not that we’ve decided to be anti-social, we’ve just been working on some new ideas, keeping busy with new projects, and getting ready for something big. Somehow in the midst of all of this, we’ve managed to visit one of the pains we always feel when approaching a new project: validation.

As most of you know, it’s part of our philosophy to address pains only when they begin to form roadblocks. Given our full adoption of FubuMVC and the way we approach software, we realized this pain wasn’t going away anytime soon and nothing seemed to “gel” with our current stack. As a result, the “Valcon” (Validation By Convention) framework was born.

What it is

The description is pretty straight-forward: “validation by convention”. Valcon provides a semantic model for describing the validation rules you have defined in your system. It also provides a runtime version of the configuration model so that you can execute server-side validation (as you’d expect from a validation framework). The registration DSL allows for both conventional and specific registration of rules (more on this later).


The examples I’m about to cover can all be found in the “HelloWorld” project found in the core repository ( If you’re familiar with StructureMap, you’re going to feel right at home. A lot of the underlying functionality is very similar right now. This will most likely change as Valcon gets its own DSL “flavor”. Until then, we owe a ton to Jeremy Miller.

Basic initialization:

Two things to note here: 1) we initialize Valcon with a CoreRegistrationRegistry and 2) we tell Valcon that any dependencies we have in custom validation rules should be built with StructureMap. The CoreValidationRegistry simply scans its namespace and includes any registries it finds so we’ll skip that one. If you want to take a look at it, checkout:

Let’s take a look at a basic validation registry that leverages a conventional approach:


First we setup a scanning operation, include the calling assembly, and include the namespace containing our ModelMarker. Then we use a couple of baked in conventions: 1) apply rules based on Valcon’s validation attributes and 2) make sure that any models we find inherit validation rules from their parent types (if any).

Next we tell Valcon that, by default, any property with a name that contains the string “email” should be an email address and any property with “phone” should be a phone number. We don’t really want to specify required fields at this level but these conventions are helpful and cut down on code.

Now let’s take a look at the most useful application we’ve found for all of this: direct integration with Fubu’s HTML conventions.


We’ll cover all of this in detail in upcoming posts, but I wanted to get the core concepts out there today. The main thing to note here is the usage of the ValidationGraph class. This is the configuration model that you can scan and obtain all information from. Every model type has an associated chain of validation calls which can then be filtered by the properties that they apply to.

Check us out on github and give us some feedback! We’ve got a mailing list open at:

This entry was posted in Development and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>