Validation Design and Documentation

Question

In a perfect world you have the validation (verification) of inputs in the business logic layer, not in the presentation or persistence layer. In reality you can (or want) to place it anywhere.

Lets make a simple sample (web-application using a framework like JSF or ZK): A certain input field accepts 4 digits between 0001 and 0500.

1. You could use the constraint features of your web framework to do this. Convenient for user, no additional server load.

2. You could do it in business layer (eg java-ejb). Foolproof because all applications using the same ejb will use the same validation. Eventually not nice because you need to throw back error at user after evaluation. Needs roundtrip to and from server.

3. You could rely (partially) on the DB to fail if someone enter (via persistence layer) a non-digit value or a value with more than 4 digits. Ugly.

Resume: You would do it (redundant) in 1. and 2. (Make it nice for the user and make it consistent for all applications). (Plus the length of DB col would be 4 )

Now the QUESTION: How you document this validation ? Text document or an UML diagram ? In a way you have business logic in up to 3 locations. In complex systems this close to impossible to track and understand.

Real life scenario for above sample: You need to change from 4 to 5 digits. Without documentation you need to hunt for the locations where changes might be required.

Whats you experience ? Any tips or tools for this ?

cheers
Sven

Answer 1

In one of my projects, I was able to do all of my validation using regular expressions. Luckily, my database (PostgreSQL) supported regular expression constraints. I was able to use regex validation across the entire application with ease by having the regex defined at the database schema level. This was then inherited by the application logic and then by the client-side javascript validation engine.

Since, my coworkers and I were all SQL fluent, it was self-documenting to us. A quick check of the database's table definition would tell you the validation rules. If we needed formal documentation generated, it would be trivial to pull the information out of the database metadata.

I know my experience here is a bit unique, but I want to highlight how regular expressions are a portable solution that is relatively self-documenting.

Answer 2

The trick is to adhere to the DRY (don't repeat yourself) principal.

There are several different ways of reaching this goal:

1. define constraints in DB (Elijah's method) that are propagated to business and UI layers
2. define constraints in business layer (Java) and run the same code in the UI using GWT
3. Etc., I'm sure there are plenty of other methods for achieving the same results.

Duplicating the constraint in different places, and then "documenting" it (adding another duplication!) is a recipe for inefficiency!