I'd go even further than Bear and say you should perform validation on EVERY layer boundary.
So the client performs validation to catch what it can, then the servlet engine performs validation for data integrity and security. When that servlet calls an EJB that EJB performs its own validation (after all, it could be called from elsewhere by a process that isn't controlled closely). If that EJB calls a mainframe, the mainframe again performs validation.
And on the way back you should put in sanity checks as well to see if the data you get back is within expected limits, to prevent things like man in the middle attacks (or merely working with data from a corrupted database).
Originally posted by Jeroen T Wenting: I'd go even further than Bear and say you should perform validation on EVERY layer boundary.
My model and business code also performs data validation. Since the business/model code is written to be completely independent of any UI, it has no idea where the data is coming from. A Swing UI? The command line? Other?
Remember when your mother used to say "Wash that! You don't know where it's been!"?
Same principle applies. [ August 21, 2006: Message edited by: Bear Bibeault ]
Speaking on performance, do you have benchmarks to support your worry that too much validation will slow down the server? Granted, complex business validation aside (such as those that would require a trip to a database), most validation like string parsing and number formatting can be handled quickly. If you're really concerned in a particular implementation, I'd run benchmarks with and without validation and then weigh the results.
As for me, I agree with validation should be done at every boundary but there are areas you can optimize (or rather different boundary lines you can draw) such as restricting access to ejb/web certain components based on where the request is coming from and then adding full validation on that outer layer.
[ August 23, 2006: Message edited by: Steve McClintic ] [ August 23, 2006: Message edited by: Steve McClintic ]