That's much better.josh wrote:The paragraph immediately following the content you just pasted reads:
'The above scenario is the goal; however some duplication, especially for validation purposes should exist in the client as well. Such rules should be reinforced by the business layer. Furthermore in some systems for reasons of extreme performance benefits such as batch updates may cause an overriding exception and should be placed in the database. So a more realistic approach appears as follows. Note that 100% still exists in the business layer and that the minimal pieces that exist in other layers are actually duplications and exist solely for the purpose of performance or disabling user interface fields according to selections, etc.'
Constraint validations implementation is a must - that ensures the integrity of your DB.josh wrote:And actually I personally handle cascading deletes / etc.. in the business tier personally. That is actually preferable. Constraint validations if implemented should be in addition to the business logic in the business tier, IMO. Once a single piece of business logic is involved in an operation it should be moved into the business tier entirely in 99.99999% of situations.
Frankly, I can't see how these two are so different: having a PHP code that catches constraint exceptions in multiple queries, or having a PHP code that catches exceptions fired by a call to a stored procedure.
Now let's talk about something different - DB transactions. How do a transaction relates to the business layer?