Erik,

I was just reading your message for the first time - what a great response!

I encounter that type of question frequently. Doesn't it frighten you, though, to not have a central repository for your business rules? It almost leads to the kind of confusion which existed before n-tier design became a recognized and accepted pattern. If you change your server-side rule set, you gotta remember to change the identical client side rule set!

I don't today see a way around it (unless you could create some sort of business code generation system which updated the code for the client side), but it starts to give me that feeling of out-of-controlnes which I so try to avoid.

It's a very interesting and though provoking issue. Are you aware of any people who have written on patterns to apply when doing such coding?



>> This most cetainly breaks n-tier design. The control UI should not know anything about the business rules. Validation for uniqueness should be done in bizrules object.
>
>I am not a MM programmer, but have a comment or two on the above assertions.
>
>I don't agree that giving a control knowledge of business rules is necessarily a violation of n-tier principals. It only is if the control is solely responsible for enforcing this rule, but duplication of logic often cannot be avoided. Take for example a web page that uses client-side script to ensure that the user enters all of the fields on a form. The data tier should have rules in place to ensure that all of the required fields are present, but for the sake of interface speed and conservation of server resources I see no problem with duplicating this logic in the client.