Forget server-side form validation with a good domain model?

Question

I am developing an MVC application with Zend Framework and jQuery. My Model consists of three layers: Service Layer, Mapper, Domain Model.

To date I have been struggling with input validation - some happens on the client, some in the Zend Form, and some in the domain model. The responsibilities have become confusing and there is lots of duplicated logic.

After giving it some thought, I can't see any reason why I wouldn't skip doing any Zend Form validation. I can validate simple things (including regex) using javascript, and get additional data from the server when required (via ajax). When the form passes validation, I'll pass it through to the server.

Of course my domain model logic will need to be comprehensive (duplicating all that's on the client), but what else is a domain model for, right?

Am I missing anything? Are there any gotchas to watch out for?

EDIT: Just to be clear, I am not suggesting abandoning server side validation at all. (I realise that this is imperative.) I am suggesting that if my domain model does it, there is no need to do it in the form as well.

I'd say: _always_ validate on serverside. People may not reach your model only via your web page... so be prepared for this. — gustavohenke, Jun 28 '13 at 04:32

score 1 · Answer 1 · answered Jun 28 '13 at 04:39

No. Anyone can modify your client-side Javascript and force your client-side code submit what they want it to submit. Because of this, your server should take the attitude of not trusting (without validation) anything the client sends it. Client-side validation does not exist for security nor for protecting the integrity of data. Client-side validation only exists to improve the user experience. With client-side validation, your website can inform a user about errors without having to make a server round-trip, lowering the friction of whatever task the user is completing.

score 1 · Accepted Answer · answered Jun 28 '13 at 13:48

Your domain is not for doing anything 'after' doing it on the client.

Think it the other way around: You validate on the server, and as an extra you do it on the client to make your user happy.

First you should make sure the things you want to be validated should be done in the first place on the Domain Model (probably in the set() method).

Then you can (as an extra feature for your users) do that also on the client, BUT its JUST to give the user faster feedback on what it did wrong during input. NEVER a replacement. Its never ment to prevent the user to do something which brings your model in an invalid state.

Also when you make a model persistent, you should always check if it's in a valid state. And invalid contents will make it invalid, and thus you shouldn't save it. Also when you are applying changes to multiple models (entities) in your application, make sure you do a transaction, to validate both models and make sure not one of them is saved in an invalid state.

score 0 · Answer 3 · answered Jun 28 '13 at 07:22

Is it Zend / php specific question? If yes then my answer may not apply.

It seems that the problem you face is a multiplication of validation logic. So at server side, you want to emphasize your validation at only one place, and it is the domain model. Here is the pros:

Pros:

Easy to track, the rule is directly at your domain model
Because the domain model has the validation, any class accessing the object can do validation
When your domain model has changed, it is more natural to also change the validation

Cons:

Not-reuseable. Especially at OOP where there is inheritance and interfaces, the validation cannot be used for other domain model which has similar structure (maybe derived classes). However, this case may not apply for php.
Non-flexible validation logic. You will need different validation rules for same object in different state. For example if you want to save a request, the validation will be different for draft (can has some fields empty), published and maybe completed or obsolete.

Purpose:

Usually I do the validation by creating some specific class responsible for the validation, and not the domain model. I can solve both of the cons because it is reusable and flexible (I can has DraftValidator, PublishedValidator). The validation result can be very general, e.g having error message and isValid property.

The validation at Javascript:

It is fine to have validation at javascript level, especially to provide responsive feedback to user, rather than waiting for request/respond trip to the server.

Forget server-side form validation with a good domain model?

3 Answers3