[DUG] Stored procedures and business logic

[James Sugrue]

(IMHO) the business layer should do all integrity/error checks. The UI
should be UI only - contain no smarts - and if you leave all the decisions
to the DB then your code can be assuming a lot. 


-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Karl @ Work
Sent: Friday, 2 June 2006 11:33 a.m.
To: 'NZ Borland Developers Group - Delphi List'
Subject: RE: [DUG] Stored procedures and business logic

Neven wrote:
> b) Because the DB Server enforces the rules you have to have the UI
> guiding the user otherwise its a 'chuck at the db and see
> what happens'
> UI (ughh). if you do this then you have duplication in business logic
> (in the ui and the db) and therefore the inevitability of errors

What about foreign keys and unique indices?  Or database constraints?  To
push your statement to its logical conclusion, such things could all be
checked at the UI stage and they could be left out of the db entirely.
Personally, I think it's perfectly reasonable to have stored procedures (and
triggers) do similar checks on data validity to ensure that no code slips
ever permit crap into the database, which it seems to me was what Kurt was
advocating.  So you might end up duplicating some logic at the front and
back ends, but not to cause errors - to catch them.  Just like foreign key,
unique index and other constraints, stored procedures to do referential
checks on data validity are a safety net.

Where does referential integrity end and business logic begin anyway?

Cheers,
Carl

_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi