In a Three-Tiered Architecture Where Should Data Validation Go?

I have not had much experience with three-tiered architectures so I'm working through some of the basic concepts that are tripping me up.

Right now I'm considering where data validation should take place. That sounds like something that would fit in the business logic tier. But there are benefits of putting some form of data validation in each of the three tiers.

Presentation Tier

When writing a web application, if you can avoid a round trip, you might want to. You might not want to avoid the round trip if:

• the cost (development or throughput) of avoiding the round trip is prohibitive.
• the latency is expected to be low (e.g. intranet applications).

One way of avoiding that round trip is by performing some of the data validation on the client-side.

Most of the data validation I've encountered is very narrowly focused. For example, the user's name is validated separately from the user's age. I don't think I've ever seen cross-field validation (e.g. "A customer with status X must have a account balance below Y."). Does this suggest that the client-side validation should just be a first line of defense against invalid data?

It seems like data validation is at home in the Presentation Tier.

Business Logic Tier

Here is where data validation naturally belongs (right?). You've got a bunch of Customer objects that are being manipulated in memory. When do you want to know that your Customer data is invalid? When you try to save the Customer data to the database? Or would you rather know that the Customer data is invalid the moment you attempt to modify a Customer object in an invalid way? Personally, I like knowing that something went wrong as soon as it goes wrong.

It seems like data validation is at home in the Business Logic Tier too.

Data Tier

What good DBA would ever trust all clients of his/her data to keep that data in a valid state at all times? Enter database constraints designed to maintain the data's validity. The database constraints are the last line of defense for data validation.

It seems like data validation is at home in the Data Tier too.

Questions

The validation performed in the presentation tier is probably different from the validation performed in the data tier and the business logic tier. How does one get a good idea of what valid data is if the validation is spread over three tiers?

It would be useful if I could specify what makes the data valid in one place in the form of multiple validation rules and then for each validation rule specify the tiers where they should be enforced. It seems like this would be a fairly challenging problem to solve without some sort of framework.