Where should validation logic be implemented?

Question

When developing my interfaces (contracts) and the concrete implementations of them, both the data models as well as repositories, I find myself questioning where the validation logic should go. Part of me (which tends to win out) says that the class itself should be responsible for it's own validation (string max length, date buffers, etc), but the other part of me says this should be moved out to the repository because depending upon the persistence store, these values could change based on your repository implementation.

I think there is some validation that MUST be done at the class level and think it should probably be kept together and not change even if the repository does, which is why I tend to keep it in the class.

I am all about putting in UI validation but this is never enough since much of the UI validation can be bypassed.

Curious what people think and the reasoning behind it.

Answer 1

Where should validation logic be implemented?

Everywhere.

• You should validate at the UI level so the user gets immediate, useful feedback (ie, fill out a webform and next to it have javascript say, "password too short" so you don't get needless trips to the server)
• You should validate ANY input into the main software from the user interface. Never trust the user interface, especially on large projects or on web sites - they may be bypassed, or they may be developed by a different team.
• You should validate inputs to functions/methods/classes. These have inherent limitations that have nothing to do with project requirements (other than it be able to manage the range of inputs required). The idea here is to encourage safe code re-use. Take a class, and you know it's going to fail if you go outside its parameters - and it will tell you if it does so.
• There are a variety of other areas where validation should take place (DB, backup/restore, ancillary communication channels, etc)

It may seem like a lot of work, or extra overhead, but the reality is that there are good reasons to re-validate everything along the chain, the least of which is catching bugs before they become a problem.

-Adam

Answer 2

Validation rules should be defined at the class level in an abstract fashion that can both 1) be run in the class's native environment 2) be rendered as rules for other dependent environments, such as UI scripting or repository procedures, as needed.

This gets you the logic centralized where it should be, in the class, and ancillary validation in the UI and wherever else -- easily maintainable since it's derived from the class rather than being detached logic living in a disconnected location. All-around win.

Answer 3

I have had a lot of success putting all my validation as close to the place where the data will be held in the business layer. E.g. in the property setters. This guarantees that you're only ever passing around valid data within your business layer and also guarantees that the UI will be receiving valid data from the business layer.

To some degree this also avoids the need for a lot of validation in your data layer if your code always passes through your business layer.

The only rule I would be dogmatic about is to never trust UI level validation, as this layer is the most easily compromised (especially in a web application). UI level validation is a sweetener just to make your user experience more friendly.

Answer 4

A contract (interface) between two parties say, A and B such that both have certain obligations. What does the contract say? Is B supposed to receive validated data? If that is the case, B should not be implementing validation. But what if A is the UI? Clearly you don't want to put the validation there. Typically, its best to introduce a third party, say C. A has a contract with C which in turn has a contract with B. B expects validated data. A might send crap. C performs the validation.

If contracts are well designed, this is almost never an issue. Revist the contract and place obligations on the each of the parties. If a certain party has too many obligations then introduce a third party.