Keith Watanabe * NET 2.0

While I do think that the current standard paradigm of web programming should move from the MVC pattern to the MVBC (Model-View-Business Logic-Controller) patter, AJAX introduces a new complexity that makes me think that yet another tier can introduced: the web validation tier.  I've seen business rules engines which do something similar to this, except that the interface might be quite complex.  It does add yet another middle tier to an enterprise web architecture.  However, it's still in its infancy to really see the direction overall in all but the largest architectures.  Add on the cost, I don't know if most shops would find it worthwhile to add to their portfolio of systems.

I do see two layers in a business rules engine that are worth talking about, which are the basic business layer and the validation area.  I've talked about the business layer before in how it should be implemented.  The validation area is something that I haven't discussed yet.

The validation area is simply something that checks your inputs being derived from your inbound web request.  Most rudimentary systems have something like this.  Checking for empty fields, making sure an email address is formatted correctly, ensuring that a dollar amount isn't negative, etc.  There are some libraries out there that can handle it such as Jakarta Commons Validation.  Usually, they involve some web integration that eventually passes the validated info down to the processing layer.

However, with AJAX and web services, I'm starting to think that this piece can exist on its own server for processing.  If anything it might just exist in its own layer because it's anticipated that this layer will get hit before doing the heavier processing at the business layer.  While the processing at this layer might not be as heavy by comparison, this layer will be hit quite frequently.  But at the same time, if AJAX is involved, you'll probably want to send a response back immediately for failure. 

In the older web paradigm where you might use client side Javascript to validate the request before hitting the servers, you'd be performing double the work in terms of checking input.  With AJAX, now you're implementing client side Javascript and still working directly with the server.  So it doesn't really look practical to use client side checking anymore as you're already interacting with the server.

Because of this, it might be worth creating this separation in anticipation of the server receiving a higher amount of traffic with unvalidated input.  But if the input is considered valid, you could pass the request down to the next tier (the rest of the controller level).

The advantages of coding your web applications in this manner are the following:

• No more double coding of client side and server side validation
• Consolidated logic of validation code
• Not having to worry about whether or not your users turn off Javascript (if you're already using AJAX, then it's a given that they need Javascript turned on)
• Input between the validation server layer and controller/business layer will be trusted
• Easily able to allocate resources (servers, people) for handling a dedicated task, rather than worrying about where the validation piece should occur

The disadvantages would be:

• Potentially more servers to handle
• Yet another layer being added to an already heavy application stack
• Some potential network lag between the transfer of request from your validation layer and your processing layer
• More complexity in general

However, I'd like to note that this architecture really is meant for websites with extreme volume.  I do think it's a good idea to split up validation from your web controller side and eliminating client side validation altogether if you're moving onto an AJAX type of platform.  However, unless you deal with high amounts of traffic, you won't need extra servers or dedicated controllers for dealing with this.