J. Ambrose Little warmed my keyboard with his recent post and article "Purporting the Potence of Process" which appears in the March/April 2007 issue of CoDe Magazine.

The article takes a well written look at a topic that has long plagued developers and users alike. Where and when should validation take place?

Along the way he discusses the role of workflow in process automation and validation. His primary contention seems to be that validation is in essence contextual, meaning it should be done in the context of the specific moment in time of the objects life span.

We have all worked on systems that have validation scattered throughout the application tiers and layers. You have validation most often expressed in the database in terms of constraints and foreign key relationships.

Then there is the field level validation in the UI layer or sometimes the business layer. But I have yet to see an application where the validation logic actually mapped to the real world.

Databases make great storage repositories, but they impose a set of conditions by their very nature that don't exist in the "real world". We often hear the term impedance mismatch applied when describing ORM systems that attempt to map an inherently non object oriented structure onto an object oriented representation.

But I, and I suspect you, often find that the majority of the validation code I write, wherever it is based, is an attempt to handle the inescapable exceptions that occur when you try to impose a rigid structure on the real world.

A case in point, a system I once worked on required a first and last name value for a person. A customer actually had no first or last name, just one name. Or how about an individual that does not have a phone? A number of systems I have worked on make the assumption that everyone has a phone.

Sure there are workarounds to each of these cases, and the dozens of others that I have run into, but the fact of the matter is that to a large degree we as a profession need to rethink how we design systems, in particular how we validate and persist objects, and how we automate processes in general.

I don't know if Ambrose has the whole answer, but it is certainly worth reading his article and thinking about it!

Cheers,

Robert Porter