Fact: Users provide wrong data as input.
So we have to check this data before processing it. Btw, not only users can enter wrong data, even data provided by other systems can be wrong and should be validated. Suppose our application has the n-tier architecture as proposed by Microsoft (Application Architecture for .NET: Designing Applications and Services), using custom entity business classes and a webservice layer to provide services to a client. There are several places where you can do validation, but which one to choose?
User interface layer: validation by the client application
The first place where validation can be done, is at the client side, as close to the user as you can get. This validation is pretty easy to implement. You can choose several approaches: for example: check the input each time a TextBox (or other control) loses focus. Or the validation is done before pressing the Ok/Save button, closing the form, ...
In my opinion the second approach is better for several reasons. First of all, by using the first approach the input is only validated when the control loses focus, so you can't be sure of the input, without checking all of the controls again. When using the second approach, be sure to provide one message containing all of the controls that have data that is not correct, instead of displaying a messagebox for each control.
Building validation in the user interface layer seems to way to go. But in the new world of Service Oriented Applications (SOA), there can be multiple client applications using your services. So it's obvious each client application would have to implement validation, which is not so good (always trying to avoid code repetition!). You can argue about the code repetition thing, but since we are living in the SOA world, it's possible we don't write the client application, or our services are accessed directly by other companies. So only client side validation is not enough.
Services interfaces: validation by the webservices and business components
The next place to think about is the Services Interfaces. Since every possible client application uses one ore more of the services interfaces, implementing validation at this level seems to be a good idea. The validation logic is centralized in one place and cannot be surpassed so all data provided by any client application will be validated.
But what could be a problem is passing information about the validation back to the client. Using this approach, data can only be validated by sending it to the server and waiting for a response. So even if the client application only wants to check if the data is entered correctly, a roundtrip to the server is needed.
Next question: how to do the validation? Again, there is no answer that would suit for every situation. You could validate every property in the property set member. This is an easy solution that prevents wrong data to be stored in an object. The drawback of this approach is that you validate one property a time. So suppose your users has entered 2 values for 2 properties, they get validated after each other. This would result in a scenario like this: the users enters it's data and presses the submit button, a message is shown that valueA is wrong, the user corrects it's data and submits again, another message is shown: valueB is wrong. I guess your users would not be happy. Another solution is to build a Validate function. This function would be called after all properties are set, and would do the validation checks. This gives you the advantage that this function can create an error message that informs the user of all properties that are wrong.
Conclusion?
I think there has to be some minimal trivial validation at the client side, so no round trips are needed for example to check if the date is in the correct format. The main part of the validation should be behdind the webservices (Services Interfaces layer). When performance, is one of your main issues, you should use as much client side validation as possible, due to the roundtrips. But as always, performance is not the only issue, so there should be a balance between client side and server side validation. Clients should at least contain some basic validation rules, if your performance constraints allow you, you could consider moving some validation to the server side. But be aware that even when you use very extensive client side validation, server side validation is needed to! Any thoughts would be appriciated!