You can never go wrong in checking too much data, though as you state, there does become a tradeoff with efficiency and data validation. Ideally, every sub you write should thoroughly check the data that is submitted and error out if there is something wrong, but in practice, there are cases that are sufficiently harmless to warent skipping over those checks, such as allowing an undef value to go by if you are simply checking for non-zero values in a list of numbers.
That said, it's probably most important to make sure that the data that is coming into the server to be correct, as opposed to delegating error checking in the client. As good examples, I refer to Quake 3 and any other multi-player game; because of widespread cheating, these engine are built not to trust anything that is on the client side, and thus initiates various checks on data that is sent, MD5-like checks on various libraries used, and similar features to make sure that the client version is only using what the server will accept.
Similarly, if you are going to be collecting data from the outside world, you should make sure the server is tight on exactly what it will take, and let the format on the client side be a little slack. Obviously, you want to make sure the client format is tight enough not to cause the client side to have problems, and some checks may be useful to avoid repetitious and annoying resending of large data blocks, but otherwise, let the client format be loose.
Doing it this way also means that if you change the server to improve or tighten certain restrictions, you don't have to worry about having clients change their systems; just have some preestiablished mechanism for allowing the clients to understand the new change and reporting the error.
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
| [reply] |
Wasn't "3-tier architecture" suppose to
be the solution to this sort of thing?
Another trade-off you make when you validate
the heck out of everything is that you lose
maintainability.
It would be nice for people who will maintain
your code that you do your validation in "one place"
"One place" meaning that your validation code be
easy to find and maintain.
--
Write all your code as if all your operations
and maintenance programmers are axe murders that
know your address!
| [reply] |
Never?
Should the validation rules need to change, having the old
ones exist in 5 places may be a maintainance problem. So
you may wish to try to centralize where checks happen so
that it is easier to centralize where the tests are
stored. (Whether this is true depends on what you are
doing, how your codebase is organized, etc.)
| [reply] |
Both Masem and rbc make good points, but as in
everything else to do with programming, there is no one
solution fits all and there will always be tradeoffs
involved.
If you're writing a Web application that requires a good
deal of validation and you implement none of it on the
client side, then you better expect to take a considerably
greater number of hits on your server than had you done a
few simple checks on the client side. Not to mention
floating all that data back and forth between the two and
aggravating the hell out of end users with a slow
connection.
We shouldn't lose sight of the fact that customers pay our
salaries and alienating them for the sake of programmer
convenience is not good business (unless you happen work
for Oracle).
--Jim | [reply] |
In addition to what's been stated, what you can gain by client side checking is better usability. Web forms are a good example. Using something like JavaScript, checking can be done very quickly on the client side. This saves on the number of calls to the server application by stopping the client from running the server application with incorrect data and allows the user to see their mistakes right away without having to wait for a process to run - which would display an error about the incorrect data - then having to go back and do it again.
But like you point out, someone could modify the client (turn off JavaScript, etc.). So server-side checking remains very necessary as well.
Rich36
There's more than one way to screw it up...
| [reply] |
