Is Form validation and Business validation too much?

Question

I've got this question about form validation and business validation. I see a lot of frameworks that use some sort of form validation library. You submit some values and the library validates the values from the form. If not ok it will show some errors on you screen. If all goes to plan the values will be set into domain objects. Here the values will be or, better said, should validated (again). Most likely the same validation in the validation library. I know 2 PHP frameworks having this kind of construction Zend/Kohana.

When I look at programming and some principles like Don't Repeat Yourself (DRY) and single responsibility principle (SRP) this isn't a good way. As you can see it validates twice. Why not create domain objects that do the actual validation.

Example: Form with username and email form is submitted. Values of the username field and the email field will be populated in 2 different Domain objects: Username and Email

class Username {}
class Email {}

These objects validate their data and if not valid throw an exception. Do you agree? What do you think about this aproach? Is there a better way to implement validations? I'm confused about a lot of frameworks/developers handling this stuff. Are they all wrong or am I missing a point?

Edit: I know there should also be client side kind of validation. This is a different ballgame in my Opinion. If You have some comments on this and a way to deal with this kind of stuff, please provide.

Answer 1

On the web you probably want some kind of client-side validation as a "first gate" - check for required values and other simple validation rules, without requiring the user to perform a web request just to see that the data isn't valid. On top of that, you want a server side validation layer (either built into your domain objects, in a service layer or somewhere else) that performs the actual validation of the object properties, and other business rules.
Note, however, that domain dependent validation rules (for example that a Name has the required properties FirstName and LastName) and pure business rules (for example that if a State has been provided, Country must be USA) do not necessarily have to be in the same place.

Answer 2

• Form validation (client-side) is actually just for usability
• Business validation is the real validation

Your application would probably work without what you call form validation, it would only look less nice to the user. Business validation however is needed to prevent corrupted data.

Answer 3

The approach you are describing looks a little bit over-engineered to me. I can see it being theoretically neat and clean but it seems to me that it would be a bit too granular to map to the data in a practical situation, creating unnecessary overheads and a whole lot of classes that do very little in the grand scheme of things. When I run into things like that it tends to start to smell a little of Solution Sprawl. Also if you have a lot of per-field wrappers around primitives you've got some pretty good chances of DRY violations between your "AddressLine1" class and your "AddressLine2" class and so on or an overcomplicated inheritance heirarchy necessary to avoid them.

It's like the sixth normal form- it's theoretically interesting, but if you wrote your code that way it would take a very long time for you to get anything done and maintenance would be a nightmare.

Answer 4

If you use business domain objects to validate the form as well, which can be achieved using rather simple tools, this eliminates the cruft of most validator based solutions. In a way you want to extrapolate partial behaviour from the business domain to the form domain; this should reduce code and improve maintenance at the cost of some extra wiring. I agree with Robert. I feel this approach is better than Zend/Cake/Ci etc. It seems to go in the direction of the naked object philosophy; just dump the V and the C, go for models only: http://en.wikipedia.org/wiki/Naked%5Fobjects

Answer 5

Validating in both place IS redundant but necessary. You'll want to validate on the client so that your user has a better UI experience. It also reduces the load on your server. You must also validate on the server side as nothing coming over the wire should be trusted by your app.

Answer 6

While it seems the DRY principle is being violated, you are actually validating data in two different layers - presentation and business; validation concerns may differ between these two layers. In your presentation layer you might be concerned with specific elements related to your view, i.e in a web app you might need to return a specific validation message containing a html div so you can properly render an ajax response.

Also forms usually contain persistence related constraints such as not having a certain form field as null or limiting field sizes, while business constraints might be broader, i.e validating if a purchase by an individual in a e-commerce webapp can be allowed by verifying the his past successful purchases.

That said, there are frameworks such as hibernate validator (on java) that allow you to include validation metadata in your business entities that is checked before it is persisted or when you invoke its API to do it so manually. With it you could validate all your constraints in one place.