Business Rule Validation
Validating input against business rules is generally more in depth than validating data types. It helps to think of this as giving context to your data. A name, address, and date of birth are nothing more than a set of unrelated data. Once you have applied business rules, however, you have a customer. If business rules give your data meaning, business rule validation ensures that your data is given the correct meaning.

Datatype validation objects are much easier to share than business rule validation objects. This sort of validation is very specific to a given task or application. However, since we are breaking validation into two parts, we can rewrite our business rule validation objects as necessary and reuse our datatype validation objects. Object-oriented applications are really nothing more than a group of objects that are communicating with each other. You, the developer, are free to determine which objects will be a part of a given application. Since our validation objects are loosely coupled, meaning one object doesn't rely on another, we can change out objects as we see fit.

As an example, let's assume that in this particular application our customers need to be between the ages of 13 and 18, and they also need to be citizens of the United States. I would create a Validate() method, perhaps in a customer.cfc object, to check to make sure that the birthdate and citizenship fit the specified parameters. Although this has some similarities to our Validate() method above, the differences are worth pointing out. When validating datatypes, the formBean has no idea how the data will be used. It just knows which form the data is to take. A Customer object, however, is not so much concerned with the representation of the data, but whether or not the data presented can be used to create a valid customer for this application.

Putting It All Together
How you put this all together is really up to you and how you construct your applications. Are you a procedural developer who includes a validation template on a form page once a form submission has been detected? No problem. Your validation template might look something like this:

<cfset datatype = CreateObject("component","myApp.formBean").init(argumentcollection=form)>
<cfset customer = CreateObject("component","myApp.customer").init()>
<cfset validationBean = CreateObject("component","myApp.validationBean").init()>

<cfset datatype.Validate(validationBean)>
<cfset customer.Validate(validationBean)>

<cfif ArrayLen(validationBean.getMessages())>
    <!--- Do something to display the error messages --->
<cfelse>
    <!--- No errors. Continue the application --->
</cfif>

Since I use Mach-II for most of my development needs, I would have an event-bean declared in the mach-ii.xml configuration file for this event, and I would use that bean's Validate() method in an event filter, which is where I would also create my validationBean and, if necessary, any object needed for business rule validation.

Conclusion
Form validation isn't one of those tasks that I look forward to in the morning. Not that I particularly dislike it, but it's just one of those chores of Web development. The object then (no pun intended!) is to make form validation as easy, flexible, and reusable as possible without sacrificing accuracy or functionality.

This is one of the strengths of object-oriented programming. Rather than building one monolithic, interdependent application, it's more like building a house with Legos. This allows you to spend less time on development chores, like form validation, and more time deciding how the Legos should fit together for your application.