An application should perform data validation in a Model Object, where it can validate both
user input, and the data being fetched from a database. This validation should be performed in a
class, and not in an .xml configuration file or some similar tool.

The role of a Model Object is to implement business logic, and validation is the
single most common (and arguably the most important) kind of business logic. The fundamental
reason for creating any class is often stated as bringing together data and closely related operations
on that data. This is often the first idea taught in courses on object programming.

Surprisingly, there are many web presentation
frameworks that do not follow this simple guiding principle of lasting value. Instead, they encourage the
application programmer to separate data and logic, by doing validation either in
Java Server Pages, or in configuration files (typically an .xml file).
What is the justification for this? There does not seem to be any.
If the reason is that "it allows validation to be configured", then this seems like a dubious argument.
Is it the job of a deployer or a page author to make decisions regarding important business logic?
No, it's not. On the contrary, for most organizations, allowing such casual changes to
business logic in a production environment is regarded as highly undesirable, and is thus an argument
against such techniques, not for them.

Fundamentally, validation is a programming task, and it always will be: it involves logic.
It's not a presentation task, and it's not a deployment task. Presentation frameworks
which provide validation tools are "leaking over" into the domain of business logic, in an
apparent attempt to increase their list of features. However, this style is inappropriate for the
application programmer, since it breaks a fundamental rule of object programming.
Thus, such style of validation should likely be avoided.

Implementing validation in Model Objects is simple and natural. As usual, any common
validations can be factored out into utility classes. In addition, writing test cases is simple, and
can be executed stand-alone, outside of the web environment.

Example

To assist the application programmer with common validations, the WEB4J tool
defines a
Validator interface,
and a
Check class
which returns some common implementations of that interface. Validation is implemented entirely in code, and never
with JSPs or configuration files. Here, a Resto Model Object uses Check to perform
all required validation in its constructor, by calling validateState: