Automatically Duplicating Business Logic on Web Client

Question

Last week I implemented a date validation in our front end, a combination of ASP.NET and heavily dependent on lots of JavaScript code to avoid server round-trips until a form is actually saved. I felt it clumsy that this rule check is not done on the server, but our current architecture and performance requirements prevent this. It's out of my hands for now.

Ideally, this check should be done in both places, but then the server side check would be done with neat, typed, C#, and immediately visible to developers working on that BO, and the client side check is actually done by not even a copy, which is dodgy, but completely different code.

What ways could there be to actually duplicate the server side check on the client side? Using a rule engine, and having an identical rule applied by two trusted rule engines on each side, actually delegating the server check to be done by JavaScript, which is then registered in the rendered client seems like another option, but seems challenging.

Any ideas on this rather academic versus practical question?

Answer 1

ASP.NET's Validation Controls can do this.

ASP.NET validation controls also provide two ways of validation: Server-side or Client-side. The nice thing about these Validation controls is that it will preform client-side validation when it detects the browser is able (unless client-side validation has been disabled). Thus reducing roundtrips. And it will preform server-side where necessary. This client-side/server-side detection and validation is done without extra work by the developer!

http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=46

Otherwise, you would have to follow the same model. Create set rules, then implement each of them on both sides (in controls, if you can). Then, allow the developer to select which rule to apply to which html controls.

Answer 2

Well, you'll never be able to automatically duplicate server side validation code in the client, because

1. the languages (javascript vs. C#) are too different
2. the server side code often will have data available that is not present in the client

However, it's perfectly feasible to delegete the validation code to the server altogether. Certainly, for exactly the same two reasons, that's the best place for such code. Using Ajax techniques, and the WebRequest object, a short validation stub in the client can quite easily call a server-side validation function with no need for a postback.

Answer 3

See: MVC Validation - Keep it DRY with a service layer - What is best practice?

The best solution I could find is the one that recommended decoratations on your view models, which using MVC, can produce some validation on both the client and server.

Answer 4

I've never done this, but it seems like you could write your validation code in one place on the server, then have your web application access the validation code directly while each client page accesses the same web-service-exposed code using AJAX.

In the .NET world, this could be done simply by writing the validation code as a web service. The AJAX-clients and the server app itself would call methods in this web service to do validation (note: this might be a bad idea from a security perspective - I don't know).

Answer 5

I think a simple rule engine is your best option. Depending on the validation you want to perform it needn't be too complex.

Anything else will involve additional round trips to the server (to perform all validation in C#) or getting the server to execute the JavaScript (which is much harder, I believe, than implementing a rules engine).

The only alternative is duplicating the code (just as Microsoft does).

Answer 6

The good practice is that the system entry should have the validation to make sure consistency is maintained. So, in your scenario the entry of your system is the web application back-end. So you need to have the validation on that side. Let me give you an example, let's say I create an automation tools that posts data to your web application and no UI is involved then, still if the tool does not provide the firstName, it should fail to record data.

From your explanation it seems your web application contains the service layer as well but this will be much more obvious when your system is divided into a service layer and a web application (as the dumb UI) just to collect users input.

Now you still need to (or at least it is better too) put ui validation for UI as well as you mentioned for a better user experience. UI validation should not be placed for to really prevent users from leaving the field empty in terms of data consistency, because service layer does not (and should not) let users anyway. But it is more for a better user experience (UX) so the users get a faster feedback.

Sometimes, the types of checking that happens on UI and Service layer are similar, in terms of logic. Let say first name should not be empty. Then it can be possible to share the logic, somehow, but many times, you cannot do the checks on client side, because you need some external data, resources, information... for validation. For example numbers of available stock item cannot be less than 10. In this case you cannot have that information, or if you could, it is irrelevant. Because you must be validated on the saving part, which will probably be changed by the time user submits the form.

So if this is a scenario that you have fixture of these two types of validation, then it is better to use a service side validation, and on client side also, you pass information (in async manner) to service and return the result back. Something like this service side decision. If you have the mix of these validations in one scenario, then I would not even bothering splitting them on UI only and service validations, for the entire validation I would go to service.