Re: Back-End Vs Front-End

From: Ralph <nt_consulting64_at_yahoo.com>
Date: Tue, 28 Mar 2006 08:49:51 -0600
Message-ID: <vcSdnYrXFNU-1rTZRVn-tQ@arkansas.net>

"AcCeSsDeNiEd" <dillon_at_SpamMinuSaccessdenied.darktech.org> wrote in message news:4tqh22pfh4bot3ikcu327lejpv85c30ohn_at_4ax.com...
> Hi,
>
> What is the norm when a front-end programmer (e.g VB) designs an interface
for a database (e.g
> Oracle)?
>
> Specifically, I mean should the front-end programmer hard-code constraints
like null/nullable fields
> into his/her interface, or should he/she just output the meaningless
Oracle errors to the user? (e.g
> via the VB interface).
>
> I was thinking there are good and bad things about the front-end
programmer hard-coding/duplicating
> the "controls" into their program.
>
> The bad: if the DBA un-nulls a field on the Oracle DB, the front-end will
still insist on a input of
> data for that field. The DBA must tell the programmer to do some re-coding
and re-compile the
> front-end.
>
> The Good: if certain fields need to be unnulled (e.g for some
data-migration), it will not affect
> the front-end. That means data-entry staff can continue to data-entry and
all the "checks" will
> still in be place.
>
> So what is the norm?
>
> Thanks
>
> To e-mail, remove the obvious

You are kind of asking - how to best manage chaos?

The answer lies in a combination of some common sense self-imposed discipline and layers of indirection.

Your example of 'Nulls' defines a need for the former. The attribute of nullibility should never be treated lightly. A DBA that does, probably needs to be replaced.

The latter is just a mechanism for 'buffering' business rules against storage and concentrating 'change' in one area. Personally I would never consider passing on storage constraint violations to the user. The program should only inform the user of the validation constraints it imposes.

A quick example, would be where a program has a field for NickName, and it was once Nullable, and now gets changed to NoNulls. 1) The DBA has to come up with a substitute value - else the archives are now in violation. Perhaps "NA", "NONE", etc. 2) If she doesn't and this is something new - then it is up to you to come up with something.
2) In your business layer you simple apply the rule...

     If Len(txtNickName.Text) = 0 Then
        sNickName = "NONE"
        ...
     'or

    IIf (!NickName = "NONE", "", !NickName)

A better way to manage the above is through views and storage procedures. ie, move the above rules into a SP and the program never needs to even know there has been a change.

hth
-ralph Received on Tue Mar 28 2006 - 08:49:51 CST