Dev Thoughts

Much debate was/is going on about validation and its proper place in the application. Many try associate validation to a specific tier or layer of the application. Some say it belongs to the backend while others say it belongs to the frontend. Another common opinion is that it actually belongs to the domain model.

Personally, I strongly support those who say that validation doesn’t belong to a specific tier or layer in the application. It is rather a contextual issue that may be needed anywhere in the application and differ depending on the context. The best way to explain it, is by looking at an example… a real-world use case.

The Use case:

There’s an Account entity in the system. The user of the application should be able to add an Account. The Account has the following properties:

- username
- password
- shippingAddress
- billingAddress

(of course the real Account has many more properties but for this example these properties suffice)

Typically, there will be a form that the user will use to add an Account. A real-world form would probably be a bit more sophisticated then just showing text fields for all the properties. There should probably be another password field for the user, to re-type the password for confirmation. Another common requirement is that the form should be smarter when it comes to the billing and shipping addresses - there should be a checkbox that says “Use billing address as shipping address”. When this checkbox is checked, the user will only need to enter the billing address and the system should make sure that the shipping address is the same.

In a typical architecture, the form will be submitted to a web controller that will process the user input and in turn call an “addUser(…)” method on the backend.

Validation:

there are 3 types of validation that concern this use case:

1. The two submitted passwords should be matched. If they don’t match the user should re-type them.
2. The submitted fields relate to the user properties as their values. Obviously there are certain constraints on these properties that the submitted values should adhere to. For example, the billing address cannot be null, the username cannot be empty, and the password needs to be between 6 to 8 characters long.
3. The username should be unique in the system. That is, if the submitted username is already in use by another account, the user should enter a different username.

I specially chose these 3 validation types, for they map quite nicely with the different tiers or layers in the application. Let’s examine how:

1. The first validation is making sure that the user has typed the password s/he intended to. This is a pure frontend tier validation, for it deals with the user experience on the frontend. Theoretically, if for example the user had to choose a password out of a given list of passwords, there wouldn’t be any need for this validation - it’s all about how the user works with the presented form. In any case, whatever form is shown, both the backend functionality and the domain model (the Account entity) stay the same, so this type of validation definitely doesn’t belong to either of these tiers.
2. The second validation is making sure that the values of the Account properties adhere to the domain model constraints. As you can guess, this validation strictly belongs to the domain model layer. The domain model is a vertical layer - it is used and accessed by the other horizontal layers. So are the constraints for the model. For example, on the frontend, it makes sense that that form presented to the user will be “aware” of these constraints, and force the user to enter only values that adhere to them. On the backend, it makes sense that these constraints will map correctly to the database if the domain class (Account in this case) is persisted. Since these constraints are practically used everywhere the domain model is used, it only makes sense to couple them together.
3. The third and last validation type is to make sure there are no two Accounts with the same username. This is a classic business rule which naturally fits in the backend - where all business rules belong. Putting this validation in a different tier is a clear mistake. For example, if put in the frontend, then when another interface is exposed for the backend (e.g. web services) this rule is absent, and if not implemented in the new interface, will be lost and the application may be left in an inconsistent state… clearly a mistake.

The example above clearly shows that when talking about validation, the first question that needs to be asked is “what type of validation?”. Once this question has been answered, the next step is to start thinking how that validation should be implemented.

next stop… Validation in practice

This entry was posted on Thursday, January 12th, 2006 at 3:29 am and is filed under General, Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.