Part One of a Series on Replicating Validation Logic Between Client and Server [modified]
-
Very often it is advantageous to invoke certain validation logic on client and server, especially if they are not always connected, or if another, uncontrolled client uses the server. I mean less of the simple validations, such as 'Surname must be present', although I don't exclude that, but rules such as a document billed date should generate a warning if more than thirty days before or after the current day. A ideal solution would be one server validation engine that receives client requests to check single rules, or even a collection of rules, before the more expensive submission of the whole document. Some constraints, such as minimising server requests, or allowing the client to perform a validation and local saving of a document while disconnected, exclude this solution. A possible solution after that is to use the same validation library on client and server, which has the advantage that additional, external clients could also make use of that library. One happy family, all using the same properly designed, implemented, and tested library. The biggest, and in my opinion, most common problem with this is with web applications. Validation code on web pages is normally done in JavaScript, or a higher order JavaScript library, where the server validation code is written in C#, VB.NET, Java, etc. This means the validation code cannot be shared, but must be separately implemented in another language, probably by another coder. Both this language and this coder handle things differently to the combination that developed the server side validation library or routines. This means maintenance to validation code must be done in two places, and in two languages, on two platforms, and for me, only two variants of this code is slightly optimistic in some cases.
Last modified: 12mins after originally posted --