6

Possible Duplicate:
Data input validation - Where? How much?

Given that I have a web application with a user facing form that will store information in a database (that will be used by other applications as well), it seems to me to be worthwhile to validate 3 times:

On the web client side via javascript to save postbacks to the server when the user enters bad data or forgets a field

On the server side because we can't trust the web client to have validated the data and saves calls to the database when the data is invalid

On the database side because this is the only way to ensure that the data stored in the database is valid.

On the one hand, this seems excessive and violates the DRY principle. On the other hand, the performance would be noticeably different if I had to submit the request, send it to the database and return an error generated by the database for bad or missing user information. What is a reasonable amount of validation?

Community
  • 1
Peter Smith
  • 2,587
  • 19
  • 21

5 Answers5

8

Usually when I've done this, I've done it all three times, but with a twist that adds value at each layer:

  • client side - checking for data errors that are so bad that they should never be sent to the server. Formatting, an light reality checks (for example - there is no September 31).

  • server side - quick pass through data validation, add business logic checks. Sometimes you can even reuse the same validation code, so you only have to write it once. A must have is the security type checks - injection, overflows, etc.

  • database - generally, I have not used the database for the same type of data validation. It's got minimal protections against format violations and size violations. But not all the quality checks that the client and the server. I don't generally presume that the database can't trust the server. The database should be checking the data from an integrity standpoint, however, for example, the server should not be posting such that we have multiple, overlapping, conflicting write operations due to a lack of data refresh.

I think you can focus in on the closest/lowest level of validation (server and database) at the expense of usability.

bethlakshmi
  • 7,625
  • 1
  • 26
  • 35
1

We use Ruby on Rails and the pattern most often seen is to validate on the server and not much else.

You can't trust client side validations anyway. At least to us a few extra posts don't matter. Though there may be situations where JavaScript can give better error messages. But I nearly never use it for that.

When the Model has validations and there are tests that ensure those validations work as expected, there is not exactly much need to validate on the database again. Not only wouldn't it be DRY, you would have to add extra logic in your code to handle any errors returned by the database. Errors that the Model should already have raised.

If you can't 'trust' your code, your problem is quality control, not where to place (or repeat) certain parts of it. Proper unit tests should make sure that such things work.

thorsten müller
  • 12,058
  • 4
  • 49
  • 54
  • "You can't trust client side validations anyway" @Thorsten, can you point to some reasoning for taking this position? I'm seriously curious, being relatively inexperienced; not being sarcastic here. – StevenV Aug 16 '11 at 17:05
  • @StevenV: In general, don't trust anything that comes from a browser. Your website and JavaScript are readable for the user. He can change the JavaScript to begin with. If you submit a form, the data entered becomes part of the URL and can be changed easy enough. – thorsten müller Aug 16 '11 at 17:23
1

Approach client side validation with the user experience in mind.

Server side validation should sufficiently prepare your data for storage in the database.

leo
  • 1,198
  • 1
  • 9
  • 14
1

The only place you HAVE to have validation is in the application. Validations in the client are, as you say, polite but unnecessary. Validations in the database should be "databasey"--ensuring uniqueness of unique keys, etc--and can mostly be set up as part of table definitions.

Just looking from the DRY concern... I've never really thought about this before, but it might be possible to use AJAX calls from your javascript to run validation routines on the server. Then you could reuse those same routines in the application.

Dan Ray
  • 9,106
  • 3
  • 37
  • 49
0

If you want to be more DRY, you can try to have a declarative form of validation somewhere (in the business layer, but the declarations can either be in code only or else you can have metadata classes stored persistently) which is the basis of all validation code. The validation code on the client probably won't exactly match the server (besides just being written in another language), but that's fine. It's DRY if you send the declarations themselves to the client to be interpreted, or if you use them to generate more specific java script code from the server.

DB validation rules can't really be done this way unless you generate the database from a model, and that's more trouble than this is worth.

psr
  • 12,846
  • 5
  • 39
  • 67