If I understood you correctly, I disagree. It is definitely the job of the middle tier to validate user input. However, it IS common practice to do this in the UI (I do all the time at the request of the user) so the user can get feedback as they step through each field in a form (as an example) instead of after the form is completely filled out and submitted. However, implementing validation in the UI does NOT free the developer from the requirement of implementing it in the middle tier -- mainly because that same middle tier could be called from a different UI and would still require that validation and business rules be processed.

Tracy

>Hi, Kev.
>
>>Following on from your example, one thing I've just been looking at is validation of entered values.
>>
>>My first reaction was that the middle-tier should check validity of passed values, because the UI doesn't need to know what data can be accepted.
>>
>>So if say, entering a product code, you accidently put a space in the middle, should the middle-tier be the tier to pick that up and return an error code?
>
>As usual, that depends. In many cases this can be handled in both sides.
>
>For example, your mid-tier can (indeed, it must) perform a final validation before commiting the transaction, to be sure that everything went ok. As I said, if you're just trying from the command window, you basically have no validation at all, but the BizObj should be smart enough to avoid processing wrong values.
>
>Beside that, checking values interactively all the time would mean a lot of traffic between tiers, so the basic validation could be done client-side, to avoid the user to enter bad values and report her about that at the very last moment.
>
>Indeed, this is the normal procedure. In a VFP client you can make wonderful realtime validation. In a web page (different fron-ent, same middle-tier), you are usually mucho more limited in what you can validate on the fly, and have to wait until the user clicks the submit button.
>
>Are you figuring the whole pattern?