Keith Watanabe * NET 2.0

I know there's been a new trend starting where people are using AJAX to replace the double coding of client/server-side type of validation in web programming.  I'm still attempting to come up with a better architecture for this as part of me wants to believe that even splitting up validation as a server component may lead to more scalable systems (i.e. dedicating a server for purely validation SOA purposes).

That said, for those trapped in the pre-AJAX world, the thing is that most  people validate on the server side.  But as a strategy, server side validation can pose some  programmatic difficulties and I believe that those difficulties are inherent in both AJAX and non-AJAX enabled applications.  Those difficulties are:

1) Complex form validation (e.g. where one field depends on the value of another field to derive its answer)
2) Cases where database information must be validated (e.g. where a new user needs to check whether or not their ID exists)

For case 1), let me demonstrate an example.  Let's say you want to validate whether or not a person is of legal age to utilize the site.  So a generic solution might be to have the user enter their birthday in the form of MM-DD-YYYY.  Taking these fields (assuming there's a drop down list or some input box), you have to then derive the actual date, convert it over to an age, and then examine the value to see if it falls in an acceptable range.  So what makes this situation difficult?

It all depends on how your validation system is setup.  I've generally thought about validation as simple one field with several checks as a strategy.  So one might loop over the parameters in a request form and compare those expected parameters against a set of validations.  But if you get to a situation now where you're creating a dependency between those parameters, you're kinda out of luck and have to rework your structure.

Alternatively, you could structure your validations one step higher, perhaps in your business layer or controller layer (if you're using an MVC type of architecture).  It's actually easier there since you've essentially filtered out most of the bad data and can force your business layer to make the real decision whether the date being assembled is a correct age or not (or even just checking whether or not the date is a date). 

With the difficulty 2), the problem occurs in that you might be injecting your sql at the validation level.  Depending on how you want to organize your architecture, this might degrade the performance of your application.  Or it might disrupt your current architecture since some applications might perform these checks at the stored procedure level.

This said, I must pose the question: what is server side validation?  Or perhaps a better question is: what is good server side validation architecture?

In my book, good server side validation architecture should be simple.  That is, one parameter gets type checked.  You can check for nulls, the format (integer, float, url, email), a specific range (min/max), and may even check groups of similar data, using loops to iterate over similar data (e.g. a form allowing a user to send out multiple invitations to friends, using the same email parameter).

The age validation problem is more difficult potentially.  Again it might just be me and how I handled my routines.  The data validation part is more tricky because now you're attempting to inject your data routines at a potentially higher level.  To me, both of these areas are better handled at the business layer.  My feeling is that data that reaches the business layer should be "clean" (that is, you're getting what you expect).  You don't need to perform any additional cleansing on the data.  So if you're expecting an integer for a user's id, you get a number rather than a string.

The business layer should be making more decisions about the type of data that should go in or be used.  While age can be a decision in that it acts as a range, it's also a business decision to some extent.  Also, the case of the existing user id, email or whatever unique key is much lower in terms of location to be checked.  So placing this check at the business layer makes a little more sense if you're segregating your architecture.

All of this is arbitrary, naturally, and should really be centered around your vision of architecture.  However, I think there needs to be some general guidelines for handling this type of architecture.  In addition, this is a common problem to most web applications and this approach, imo, is a sound one.