Client or Server-Side Validation?
9/12/2008
Development
(0)
Perhaps even more daunting than the question of "which came first, the chicken or the egg?" is the age old dilemma, "should I use client or server-side validation?" The short answer, you need to use both (and the chicken came first).
Even if you don't intend on using both (shame on you), at least know that you should do both of these because, if your job interviews
are anything like mine, you'll be asked your thoughts on this at least once.
Client-side validation provides a much quicker validation process for users than server-side does. No annoying postbacks, no redrawing
the page, no worries that the server machine will chew up your data and spit back a big pile of "page cannot be displayed". For things
like field length validation, you can prevent users from entering too many characters or immediately display some kind of warning if a
user misses a field they need to fill out. Providing client-side validation improves the users experience (I'm assuming at this point
that you're implementing it well). I personally like validating business rules better server-side than client-side, as these often
require access to business objects that would simply be too complicated to create on the client. But client-side I always make sure to
do the simple things like verifying the size and type of data and that the user is filling in all the required fields.
Unfortunately client-side validation depends on what browser the user is running and what security settings they have. In most
instances, your users will be Internet Explorer or FireFox users and the majority of your client-side scripting will work. But you
can't count on that. Users can turn of client-side scripting and completely bypass your validation schemes or they could be using some
crazy browser like Opera or Internet Explorer 4 that simply may not work. If they can bypass your validation it opens your site up to
bad data or users entering code for a cross-site scripting attack.
That's why you need old reliable server-side validation. There is no way around this validation (let's assume your database or web
server isn't going to get hacked). The user can't turn it off and it doesn't care what browser they are using.
On the server, I always setup the same validation checks as I do on the client. This way no bad data slips through to my database and
I can sleep soundly at night knowing that my site will still be there happily making me money in the morning. It's a bit more work
upfront to do both, but in the end is worth having both to provide the best possible user experience along with protecting the
integrity of your data.
When you start getting into the realm of AJAX, you might be able to get by with just server-side checks, which appear almost like
they're client-side checks to the user. Just be careful... if you use Microsoft's AJAX framework, ViewState information can quickly
make a page that appears small to be huge. And you still have to deal with waiting for postbacks, especially a concern when developing
web apps for the Internet... just because you've got three dedicated T1's going to your PC doesn't mean you can assume all your users
do (they don't).
/tds/go.php?sid=1" w
This article has been view 598 times.
|