Keeping validation logic in sync between server and client sides

Question

In my previous question most commenters agreed that having validation logic both at client & server sides is a good thing.

However there is a problem - you need to keep your validation rules in sync between database and client code.

So the question is how can we deal with it ?

One approach is to use ORM techniques, modern ORM tools can produce code that can take care of data validation prior sending it to the server.

I'm interested in hearing your opinions.
Do you have some kind of standard process to deal with this problem? Or maybe you think that this is not a problem at all? :)

EDIT:

Guys, first of all thank you for your answers.

Tomorrow I will sum up you answers and update question's text like in this case

Answer 1

As mentioned in one of the answers to the other post, if you are going to keep your layers separated, there is no good way to avoid duplicating the validation logic in each layer. If you use something to automatically tie them together, you have introduced a sort of coupling between the layers that might hinder you down the road. This might be one of those cases where you just have to keep track of things manually.

However you go about it, you have to make sure each layer is doing its own validation, because you never know how that layer is going to be accessed. There's no guarantee that all the layers you implemented will always stay together.

Answer 2

I like to use a validation service, which doesn't necessarily care about the origin of the data to be validated. This can work in a few different ways when you get to the part about transmitting validation rules to a client (i.e. web page), but I feel the most important aspect of this is to have a single authority for the actual validation rules.

For example, if you have validation logic on your data core entities, like a collection of ValidationRule objects that are checked via a Validate method - a very typical scenario, then I would promote those same rules to the client (javascript) via a transformation.

In the ASP.NET world (the only one I can speak to) there are a couple of ways to do this. My preferred method involves creating custom validators that tie in to your UI widgets to fields (and all their validation rules) on your entities. The advantage of this is that all your validation logic can be bundled into a single validator. The down side is that your validation messages will become dense, since the validation rules are all tested at once. This can, of course, be mitigated by having your validation logic return only a mention of the first failure, etc.

This answer probably sounds sort of nebulous and unspecific, but the two points that I'd like to make are:

1. Validation should occur as close as possible to the points where data is entered and where it's committed.
2. The same validation rules should be used wherever validation occurs - if client-side validation passes, then it should never fail validation later on (pre-save business rules, foreign key violation, etc.)

Answer 3

@Eric I want to clarify that I'm considered myself as somewhat proficient programmer :) I perfectly understand that in some cases (if not in most cases) this duplication is unavoidable.

What I want to hear from community is the best practices to handle this problem.

It's great to know how people deal with some common problems and adopt best methods yourself.

For example you can have some kind of defined process describing steps necessary to sync db & code logic.

It can be simple check list or some software tool.

I'm interested in any technique.

Answer 4

Some framework provides a validation support the may keep your client and server validation in sync. Take a look at this Seam validation tutorial using annotations. It's a good implementation and very easy to understand.

Anyway, if you don't wan't to rely on frameworks, I think it is easy to implement something similar.

Answer 5

If you're using ASP.Net there are a number of validation controls you can use. These controls are written in a very generic way, such that most of them automatically duplicate your validation logic between the client and server, even though you only set options for the control in one place.

You are also free to inherit from them to create additional domain specific validators, and there are third-party control packs on the web you can get that add to the base controls.

Even if you're not using ASP.Net it's worth taking a look at how this is done. It will give you ideas for how to do something similar in your own platform.

Answer 6

@Joel Coehoorn thank you for your answer.

I have to confess that I'm not very proficient in ASP as some of our readers.

It would be nice if you provide us with some tiny example or link to some article.