Validation: To design for it or not?

So what is validation actually?

In general, validation is a tool to ensure that application data remains correct and consistent, both from technical and business points of view.

Validation often takes form of a rule or condition that returns a Boolean value (True or False). If you see excessive conditions in a logical split, data retrieve or attribute assignment, there is a good chance you came across a validation in disguise.

Figure 1: A common validation pattern in attribute assignment

There is no question if validation happens: nearly every application has it, yet not each one is designed for it. However, do developers need to do anything special about it?

To design or not?

Validation is an example of a so-called crosscutting concern, meaning that validation compliments core business concern in multiple parts of an application. For example, a pizza ordering system may have multiple intake channels (mobile, web shop, web-services, front office, etc…) and multiple order volumes: one by one or in batch. To maintain proper quality of application data, incoming data must be validated to the same extend in all of the above channels and volumes, which means that validation affects multiple application parts.

The more places where data is created or updated, the larger validation impact on the application.

Crosscutting concerns are naturally hard to cleanly isolate from the rest of the application. Failing to take counter measures in design, results in scattering (code duplication), tangling (significant dependencies between systems), or both.

Figure 2: Visualization of a Crosscutting Concern

The figure above illustrates impact of a crosscutting concern on an application. Each column in the figure represents a part of the application (e.g. a module in Mendix). The volume of a column is proportional to the amount of logic (or size) of the part. Red horizontal bands represent the crosscutting concern, while grey areas represent core application logic.

What does scattering and entanglement mean in practice? Here are some common issues in case of validation:

• Complicated testing because validation cannot be isolated from a business process.
• Reduced maintainability, as even a small change may have multiple impacts throughout an application.
• Increased risk of compromising data quality due to uneven extend of validation in different parts.
• Bloating of core business logic with irrelevant validation details (imagine columns without the crosscutting concern in the above figure).

In practice, issues tend not to come alone, their whole being greater than the sum of its parts.

Last but not least, validation is also surprisingly tricky to implement as Herman Geldenhuys, a colleague in Mendix community, vividly describes in his blog “V for Validation, part 1”.

Conclusion

Every application is likely to need validation. Not having a proper solution for validation needs, leaves a door open to a host of problems. The question is what are validation needs of a specific application and how to implement them?

This article is the first one in a series, which aims to help application designers and architects to find answers to the above question and give overview of some available tools for validation on Mendix. While details will be Mendix-specific, the general material should be applicable to other rapid development platforms, e.g. OutSystems, as well.

The next article will cover common situations in which validation occurs, regardless of how it is implemented.

Do you have you any experience with design and implementation for validation? Are there any specific points you want to be covered in an upcoming article? Feel free to send your comments to info@pinkelephant.co.uk.

Article by Andriy Levytskyy, BPM Consultant at Pink Elephant Netherlands.