The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Too many Validation routines in a web app?

I am writing a 3-layer web application and found that I validate a field too many times. Let's say we have a text field which is limited to 2000 characters because that is the max length the database field can hold.
Now I am implementing the same validation at three places:
1. Validation at browser client (Javascript)
2. Validation at the server script side (server script)
3. Validation at the business logic side (C++)

What's your opinion on this?
Wednesday, February 15, 2006
Thinking out loud ....

Without 1, you have a round trip to server w/ associated bandwidth and (perceived) performance issues to trap error.

Without 3, you might have issues w/ errors or data turncation if you plan to re-use your bll / dal.

Don't see a downside off top of head to getting rid of 2?

The only issues w/ keeping 1 AND 3 is that you have to maintain both, so if change from allowing 2000 to 3000 ... hmmm ... could you somehow make your client side validation dynamically render based on size stipulated in bll/dal?
brad Send private email
Wednesday, February 15, 2006
A common problem that should not exist in a standard web app. 

If your database has multiple means of being updated (say your web app, and a client server app, or even another web app) then adding the edit back a level has benefits.  Your web app gives the "closest to the user" response, but your database rule protects you from the MSHack web app that sometimes does not edit the data.

While the common response to these is to move the edit to the DB, that is not usually the best solution.  Mainly, because it is too far back in the process for the user to get a good response.  If your web app is the only thing updating the database, then keep your edits as close to the user as possible and they will enjoy the experience more. Multiple edits for the same rule are always bad.  Sometimes necessary, but always bad.

Good luck.
Wednesday, February 15, 2006
To paraphrase John Calvin: "Data integrity cannot be saved by JavaScript alone."

In any web application, JavaScript validation is helpful but not sufficient. This is because anyone can can construct an HTML GET or POST by hand and insert or update data that would fail the JavaScript validation.

So you need 1+2 or 1+3 at a minimum.

(You could abandon JavaScript validation altogether, but I would argue that users expect it in today's applications.)

Also, +1 to the concept of generating _all_ of this from the same source. DRY, yadda yadda yadda.
PWills Send private email
Wednesday, February 15, 2006
DRY = Don't Repeat Yourself

(for those who haven't read Hunt & Thomas)
PWills Send private email
Wednesday, February 15, 2006
If this problem would rarely occur in normal operations (eg. who would ever actually type 2001 characters into anything?), I would vote for leaving it on the server somewhere, so that it would hopefully only ever exist in one place.

On the other hand, "whoops you forgot to fill in the phone number" type edits should generally be done client-side to improve responsiveness.

IMO how often something is likely to happen is something that gets overlooked an awful lot.
NetFreak Send private email
Wednesday, February 15, 2006
"1. Validation at browser client (Javascript)
2. Validation at the server script side (server script)
3. Validation at the business logic side (C++)"

#1 may be necessary but it is never sufficient. As others have said, it's always possible for users to bypass client-side validation, either accidentally or maliciously.

The combination of #1 and #2 is sufficient if your web app is the only thing that will ever call the business logic. Even if you can guarantee that now, it's always possible that something else might call the business logic in the future. Therefore I would argue that #3 is also necessary.

The combination of #1 and #3 is sufficient if you know that the business logic validates its inputs, and you can display a sensible user message to the user in response to validation errors raised by the business logic component. Even so, defensive programming suggests that #2 is also wise.

In conclusion, you might be able to get away with omitting #2 but the others are mandatory.
Wednesday, February 15, 2006
Actually, I take part of that back. #1 is advisable but it's probably not a hard requirement. #3 is absolutely necessary though.
Wednesday, February 15, 2006
Agreed with validation built into business logic layer.
After all that is where the actual validation must occur (why else would someone invent terms like business rules ?)

You can have "cosmetic" validation occuring in the UI, and validation at the DAL for the sake of security/integrity.
Vineet Reynolds Send private email
Thursday, February 16, 2006
To be fair, the previous replies have got it just about right but I am going to plump for #1, #2 and #3.

As others have said, The Javascript validation is for the application user at the client end - it saves a rund trip to the server.

The database validation supports alternate client processes as well as protecting data integrity.

The web server validation ensures a meaningful and programatically controlled response to what might be classed as a general error if a database update failed.

That might still leave you a supporter of the #1 and #3 option. However if your validation were to be to do with security (like ensuring that there is not SQL code injection into an input field) then the need for the validation at level #2 becomes much more apparent.
Mike Griffiths Send private email
Thursday, February 16, 2006
A couple more notes:

You need #2 and #3 because the fields in the web app are not necessarily the same as the fields in the backend. Even if they are now, you don't want to commit yourself to that. For example, you may have dates that are input in different formats than they're stored, or phone numbers that use three fields on the web app, and one field in the backend.

Also, don't escape/filter things like apostrophes in the web app validation (unless the fields really shouldn't contain them). Do this in the part of the code that writes to the database. My general rule is: any time you're sending data from one layer to another, do what's necessary to make it safe for the NEXT LAYER only, and don't worry about other layers down the road. You can't, and it will screw up your data.
Thursday, February 16, 2006
Only correct answer:
#3, #3, #3, #3, #3, #3, #3, #3, and

#1 for fast user feedback.
#2 to protect application against data corruption
#3 to protect against coding errors for all layers in the application code
#4 to protect database against coding errors

In design by contract, it is the responsibility of /every/ routine to check its precondition contracts. It is never safe to assume that this is done by the calling code, because the calling code can be incorrect itself. And programming errors were the reason to use contracts in the first place. For this reasons I wrote #3, #3, #3, ...

The database should do the same, hence #4.

Although all routines should check their preconditions, correctly factored code will not become very complex because of this practice. Just define a function (pure of course) that performs the check on behalf of the routine.

As a side node, if you trust your code and performance demands so, you can in some systems switch off precondition checking. However, never switch off #2, because you open your system for corruption.

Unfortunately with those horrible design accidents called Javascript and SQL, you are not able to share the code of #2, #3 with #1 and #4.
Karel Thönissen Send private email
Thursday, February 16, 2006
I "solved" this problem by making the business logic validation rules discoverable by later layers.  So if I say a field is an integer between 0 and 10 in the business layer the server side and client side validation are automatically generated from that.
Almost H. Anonymous Send private email
Thursday, February 16, 2006
My two cents:

#3 is crucial.

#1 and #2 can be done half and half - as others mentioned, there's a difference between validating user input, and making sure you're applying the correct business logic.

A specific example: an order form.  A phone number can be validated in the user interface; if the user doesn't put in enough digits, go ahead and send a javascript reminder.

Whether you've purchased enough stuff to qualify for free shipping, should be done server side; don't rely on a javascript routine to watch the total.

I've heard people express this rule as "the more important the data becomes, the closer to the database it gets validated."  Continuing the example, if the customer turns off javascript and enters a partial phone number - not a big deal.  You still have a billing address and you can call information.  On the other hand, if the customer buys $5,000 worth of stuff and didn't get the free shipping they deserves, that's a much bigger problem.
Friday, February 17, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz