(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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
