You are right, but the fact is that in this case we are merging more principles, and the correct thing (as far as design is concerned) in my opinion is to let the product to deal with its own responsibilities as well, but invoke those operations from the controller and not from the view. In that way you don't break nor the encapsulation principle, nor the MVC pattern, do you agree?
On Oct 3, 5:31 pm, ORCC <[EMAIL PROTECTED]> wrote: > > ..the comment "PERFORM BUSINESS LOGIC" should immediately > > let you think that something is not 100% MVC ..you are > > performing LOGIC inside a MODEL, and not just model data > > handling. > > So, where I have to do the business logic? > > For example, I have a Product Object, and the product has some taxes > that depends on the product itself (Its category, price, origin > country, etc). > > Following the encapsulation principle of the object oriented > programming, I think that the object to have to know how to calculate > the product tax is the product itself. So I add a method > Product::calculateTax(); into the class Product. Tax calculation is > part of the business rules and tax value is inherent for each product, > hence, I guess that the "responsibility" of tax calculation lays in > the Product class. > > Why this could violate the MVC pattern? Or is the product controller > who has to know how to calculate the product's tax? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
