Yes, ladies and gentlemen, i have a day job, and sometimes i must put down the f# koolade and do real work. well... maybe not "real" work per se, but... Anyway, to that end...

I've spent some time scratching my head about the best way to integrate a validation mechanism into bistro. Now... there's not an explicit concept of a model in bistro - bistro is just the controller tier, so that means that there isn't a clear-cut point where you attach validation rules. What's worse is that data coming in from a request may, and more than likely will be split among different controllers for processing. Add on top of that the fact that some validation rules are applicable to multiple scenarios (client side, server side, at the controller level at the entity level), and you have a cluster of wonderful proportions.

I'm starting to think that rather than defining the concept of a generic "model", it's better to define a core of complex data types and associated validations. That way, you can assemble different pieces on the fly and still have a central validation definition.

More specifically - introduce the concept of something "validatable":

 
public interface IValidatable {
	IValidator Validator { get; }
}
 
public interface IValidator {
	bool IsValid(out List<string> messages);
 
	string Name { get; }
	...
}
 

Fairly straightforward. Now, the trick is using this... and not just server side. One of the main things we want to be able to do, is have the rules defined in one place, and made available to both the client and the server. That's where the Name property comes in. By being able to reference a rule (or set of rules), I can get a little fancy client-side. Let's keep with django. I can introduce a tag for making these rules available client side -

 
<form>
{% validate "memberAdd" %}
<input name="firstName" value="{{ firstName }}">
	...
{% endvalidate %}
</form>
 

And have that rule emit jquery validation instructions, as an example. All of this is fairly straightforward. There's still the issue of forward lookups - the controller generating the current form may not necessarily be the controller receiving the form, but that should all be manageable.

The trick comes when you start talking about usability. How do I manage the hundreds of different rules you're going to have here? How do I enumerate them all, how do I manage naming conflicts, how do I combine rules (notice the prominent absence of a list of Validators on the IValidatable interface)?

The answer (in my mind, at least) is composition. Let's assume a typical builder pattern approach:

 
	IValidator Validator {
		get {
			Builder<MyController>()
				.As("memberAdd")
				.For(c => c.firstName).RequireValue()
				.For(c => c.lastName).RequireValue()
				.WithRulesFrom(Member);
		}
	}
 

Now we have a set of rules, that require the first and last name fields, which will be identified by "memberAdd.firstName" and "memberAdd.lastName", and will also expose rules from the "Member" entity, whatever those may be.

Client side, we get access to this rule set through the validate tag, and use matching form element names to make everything line up. You can start playing games with defaults and overriden names and whatnot, but this way I have a mechanism of defining a set of validation rules in a single place, and being able to consume them in multiple other places.