> Don't mean to by offensive but
>
> >> Paul Heinz calls "collapsed three tier"
>
> Had me in tears - I agree you can do a 3T as a single app but you have to
> be disciplined about the location of varoius logic
<sigh> Whatever, Neven. I guess I'm just not as smart as you...
> > The notifications to then form I'd say are still compatible with three
> > tier as these are intended to do form level feedback things along the
> > lines of colour changes, flashing lights and buzzing noises.
> > The notifications of a UI change to the data modules are a
> little suspect
> > in term of 3T, but the primary intention there is to provide for
>
> Alas the truth is out 3T is not a panacea
>
> > centralised handling for standard changes, like changing field X implies
> > that field Y should now read X * field W.
>
> This I would do in the Database - another prob you'll face when you open
> your DB is all that nice logic that aint in your DB disappears
No, the notifications are for the business object layer. Having them only in
the database layer will not suffice for this. We would want them where they
are whether we were using SQL or not.
That is unless you _want_ to update each and every invoice line into the
server as it's typed or called stored procedures to recalculate the
extension each and every time the user changes the price, quantity,
discount, commission rate, etc. on an invoice line.
Either of those is a real waste of network bandwidth.
I'd rather have a business object that take care of itself completely
independently of the database engine layer and regardless of whether it has
a Deplhi form UI connected to it or is being talked to as a COM object via
ASP or whatever.
But maybe I'm just stupid.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
